Crash during objc_msg_lookup_sender (Aarch64) #125
Comments
|
The I suspect that the crash is in sending the |
|
I enabled debug and it looks like it might be crashing in looking up the class for the object. That seems strange, how could that be happening? |
|
Hi,
That can happen if the isa pointer is corrupted somehow. It looks as if the object pointer is 0x4000000000000000, which is quite suspicious and implies some memory corruption elsewhere. Is that a class that’s accessed via a class variable or via a call into the runtime?
David
… On 30 Aug 2019, at 05:54, Patryk Laurent ***@***.***> wrote:
I enabled debug and it looks like it might be crashing in looking up the class for the object. That seems strange, how could that be happening?
***@***.***:~/Desktop/gnustep-build/ubuntu-16.04-clang-6.0-runtime-1.9-ARM/GNUstep-build/apps-gorm/Gorm.app$ lldb-6.0 ./Gorm
(lldb) target create "./Gorm"
Current executable set to './Gorm' (aarch64).
(lldb) run
Process 31423 launched: './Gorm' (aarch64)
2019-08-30 04:50:26.492 Gorm[31423:31423] Bad palette selection - -1
2019-08-30 04:50:26.626 Gorm[31423:31423] Bad palette selection - -1
2019-08-30 04:50:27.017 Gorm[31423:31423] Bad palette selection - -1
Process 31423 stopped
* thread #1, name = 'Gorm', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x0000007fb61870a0 libobjc.so.4.6`objc_msg_lookup_sender [inlined] classForObject(obj=0x4000000000000000) at class.h:316
313 return SmallObjectClasses[(addr & OBJC_SMALL_OBJECT_MASK)];
314 }
315 }
-> 316 return obj->isa;
317 }
318
319 static inline BOOL classIsOrInherits(Class cls, Class base)
(lldb) up
frame #1: 0x0000007fb6187050 libobjc.so.4.6`objc_msg_lookup_sender [inlined] objc_msg_lookup_internal(receiver=0x0000007fffffcbe0, selector="\a", sender=0x0000000001159158) at sendmsg2.c:65
62 id sender)
63 {
64 retry:;
-> 65 Class class = classForObject((*receiver));
66 Slot_t result = objc_dtable_lookup(class->dtable, selector->index);
67 if (UNLIKELY(0 == result))
68 {
(lldb) fr va
(id *) receiver = 0x0000007fffffcbe0
(SEL) selector = "\a"
(id) sender = 0x0000000001159158
(Class) class = 0x0000000000000000
(Slot_t) result = 0x0000000000000000
(lldb) up
frame #2: 0x0000007fb6187044 libobjc.so.4.6`objc_msg_lookup_sender(receiver=0x0000007fffffcbe0, selector="\a", sender=0x0000000001159158) at sendmsg2.c:171
168 (sender->isa->info & (*receiver)->isa->info & _CLS_PLANE_AWARE),1))
169 */
170 {
-> 171 return objc_msg_lookup_internal(receiver, selector, sender);
172 }
173 // If we are in plane-aware code
174 void *senderPlaneID = *((void**)sender - 1);
(lldb) fr va
(id *) receiver = 0x0000007fffffcbe0
(SEL) selector = "\a"
(id) sender = 0x0000000001159158
(lldb) up
frame #3: 0x0000007fb73d8900 libgnustep-gui.so.0.27`-[NSTableView _initDefaults](self=0x0000000001159158, _cmd="\xeb\x1e") at NSTableView.m:2017
2014 _rowHeight = 16.0;
2015 _intercellSpacing = NSMakeSize (5.0, 2.0);
2016 ASSIGN(_selectedColumns, [NSMutableIndexSet indexSet]);
-> 2017 ASSIGN(_selectedRows, [NSMutableIndexSet indexSet]);
2018 _allowsEmptySelection = YES;
2019 _allowsMultipleSelection = NO;
2020 _allowsColumnSelection = YES;
(lldb) fr v
(NSTableView *) self = 0x0000000001159158
(SEL) _cmd = "\xeb\x1e"
(id) __object = 0x4000000000000000
(lldb) up
frame #4: 0x0000007fb73d8d08 libgnustep-gui.so.0.27`-[NSTableView initWithFrame:](self=0x0000000001159158, _cmd="\xaf\x1c", frameRect=(origin = (x = 0, y = 0), size = (width = 0, height = 0))) at NSTableView.m:2045
2042 if (!self)
2043 return self;
2044
-> 2045 [self _initDefaults];
2046 ASSIGN(_gridColor, [NSColor gridColor]);
2047 ASSIGN(_backgroundColor, [NSColor controlBackgroundColor]);
2048 ASSIGN(_tableColumns, [NSMutableArray array]);
(lldb)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Hi David, I don"t quite understand the question about whether the class is accessed via class variable or via a call into the runtime. The memory corruption seems to be happening during I set a breakpoint in indexSet and the object seems to be allocating and initializing itself. |
|
So it's successfully calling The first call will probably be the first call to anything in |
|
Were you able to triage this any further? |
|
The only thing I tried is running Gorm on an AWS ARM instance and didn’t get a crash. So maybe the crash is a result of some incompatible library on my laptop’s Armbian distribution.... hope to track it down further. |
|
I will reopen this or open a new ticket once I track it down further or find a simple test case. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
When launching Gorm.app the app crashes. This is during an ASSIGN macro/command being used. Could it be incompatible? Is this perhaps related to the bug that was recently fixed?
Thank you,
Patryk
The text was updated successfully, but these errors were encountered: