Opened 6 years ago

Closed 6 years ago

#9769 closed bug (invalid)

app crashes on exit, but only when not connected to gdb

Reported by: scanty Owned by: nobody
Priority: normal Milestone: R1
Component: - General Version: R1/alpha4.1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Sorry I can'tprovide a backtrace, but here is some assembly:

BPrivate::hoardLock(long&): 0x005d5b94: 55 push %ebp 0x005d5b95: 89e5 mov %esp, %ebp 0x005d5b97: 57 push %edi 0x005d5b98: 56 push %esi 0x005d5b99: 53 push %ebx 0x005d5b9a: 83ec0c sub $0xc, %esp 0x005d5b9d: e800000000 call 0x5d5ba2 0x005d5ba2: 5b pop %ebx 0x005d5ba3: 81c3ea3b0300 add $0x33bea, %ebx 0x005d5ba9: 8b7d08 mov 0x8(%ebp), %edi 0x005d5bac: b900000000 mov $0x0, %ecx 0x005d5bb1: be00000000 mov $0x0, %esi 0x005d5bb6: eb10 jmp 0x5d5bc8 0x005d5bb8: ba01000000 mov $0x1, %edx 0x005d5bbd: 89f0 mov %esi, %eax

crashes

0x005d5bbf: f00fb117 lock cmpxchg %edx, (%edi)

here

0x005d5bc3: 85c0 test %eax, %eax 0x005d5bc5: 740f jz 0x5d5bd6 0x005d5bc7: 41 inc %ecx 0x005d5bc8: 83f931 cmp $0x31, %ecx 0x005d5bcb: 7eeb jle 0x5d5bb8 0x005d5bcd: e8be15f8ff call 0x557190 0x005d5bd2: 89f1 mov %esi, %ecx 0x005d5bd4: ebf2 jmp 0x5d5bc8 0x005d5bd6: 83c40c add $0xc, %esp 0x005d5bd9: 5b pop %ebx 0x005d5bda: 5e pop %esi 0x005d5bdb: 5f pop %edi 0x005d5bdc: 5d pop %ebp 0x005d5bdd: c3 ret

I'm not sure what's going on. If you need mroe information I can try to provide it. And a suspcious file is attached, possibly causing the segfault

Attachments (1)

PaletteView.cc (4.7 KB ) - added by scanty 6 years ago.
PaletteView, show a NTSC palette

Download all attachments as: .zip

Change History (6)

by scanty, 6 years ago

Attachment: PaletteView.cc added

PaletteView, show a NTSC palette

comment:1 by scanty, 6 years ago

Sometimes when it crashes, it says the following in terminal:

pretendo: /Buildbot/nightly-uploader/workdir/haiku/src/system/libroot/posix/malloc/superblock.h:272:int BPrivate::superblock::isValid(): _numBlocks > 0

comment:2 by anevilyak, 6 years ago

Hoard is the userland heap allocator used in Haiku, so a crash there generally implies the app has corrupted the heap somehow. There are quite a few possible causes of that though, and without knowing the app better it's difficult to say, but it's generally an issue on the app's end. One possibility is a global or static object getting deleted at some point by the app, and then the cleanup routines at exit attempting to delete it again. Without knowing the app better it's pretty much impossible to be more specific than that though. Also note that when it crashes, a backtrace should get dumped to syslog if that helps.

comment:3 by anevilyak, 6 years ago

You could also try running the app with malloc debug enabled to hopefully catch where things are going wrong sooner, c.f. https://www.haiku-os.org/blog/mmlr/2010-02-08_using_malloc_debug_find_memory_related_bugs for instructions on usage.

comment:4 by scanty, 6 years ago

Please close this bug as well. I don't remember exactly how I fixed it, but I think I found the problem with malloc debug. There is no segfault anymore. I really feel the need to apologise for reporting bugs that are my own fault. Sorry guys -- you're doing a great job.

Last edited 6 years ago by scanty (previous) (diff)

comment:5 by pdziepak, 6 years ago

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.