Opened 5 years ago

Closed 6 weeks ago

#10774 closed bug (not reproducible)

Debugger crashes while debugging a Qt app

Reported by: waddlesplash Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is hrev47085. While debugging a Qt application (specifically, Designer; either by starting Debugger from the command line or by attaching to an already-running-not-crashed team), Debugger will repeatedly crash after doing normal tasks inside the Qt app (like opening and closing menus/dialogs).

I'm running Haiku inside a VirtualBox machine with Windows as the host OS.

Backtrace attached.

Attachments (1)

Debugger-900-debug-22-04-2014-13-40-59.report (20.0 KB) - added by waddlesplash 5 years ago.
Backtrace of the crash.

Download all attachments as: .zip

Change History (9)

Changed 5 years ago by waddlesplash

Backtrace of the crash.

comment:1 Changed 5 years ago by anevilyak

Is the crash consistently in the same location? At a glance, the backtrace indicates possible heap corruption, where the crashing code is more typically the victim, and as such not so helpful at tracking down the cause. It'd be potentially interesting to see the resulting crash report if Debugger is started with LD_PRELOAD=libroot_debug.so .

Otherwise, I also note that your VM is getting relatively near to using all of its memory, with >1GB of heap in the Debugger team itself, so it may simply be running out of memory, which isn't necessarily handled gracefully everywhere in the system libraries. As such, it'd also be interesting to know if increasing the amount of memory given to the VM makes a difference.

On the other hand, another possibility is address space exhaustion, as would occur when trying to debug e.g. WebKit on a 32-bit system (it's difficult to tell for certain from the given information). If that one's the case, then the only real solution would be to use a 64-bit build.

comment:2 in reply to:  1 ; Changed 5 years ago by waddlesplash

Replying to anevilyak:

Is the crash consistently in the same location? At a glance, the backtrace indicates possible heap corruption, where the crashing code is more typically the victim, and as such not so helpful at tracking down the cause. It'd be potentially interesting to see the resulting crash report if Debugger is started with LD_PRELOAD=libroot_debug.so .

No. It happens after having the debugger attached to the process for any significant length of time (~10-15s). It doesn't matter if the app was already running or if it was launched with the debugger.

Otherwise, I also note that your VM is getting relatively near to using all of its memory, with >1GB of heap in the Debugger team itself, so it may simply be running out of memory, which isn't necessarily handled gracefully everywhere in the system libraries. As such, it'd also be interesting to know if increasing the amount of memory given to the VM makes a difference.

Will try later.

On the other hand, another possibility is address space exhaustion, as would occur when trying to debug e.g. WebKit on a 32-bit system (it's difficult to tell for certain from the given information). If that one's the case, then the only real solution would be to use a 64-bit build.

Nope, not debugging WebKit here -- I'm debugging Qt Designer, which does not even link to QtWebKit.

comment:3 in reply to:  2 Changed 5 years ago by anevilyak

Replying to waddlesplash:

No. It happens after having the debugger attached to the process for any significant length of time (~10-15s). It doesn't matter if the app was already running or if it was launched with the debugger.

You misunderstand. What I asked is whether the crash backtrace in the saved report is consistent or not.

Nope, not debugging WebKit here -- I'm debugging Qt Designer, which does not even link to QtWebKit.

That was simply an example of an app/library that's not feasible to debug on a 32-bit system due to address space constraints ; I didn't say it was coming into play here, simply that Qt + Qt Designer might be hitting the same limitations.

Last edited 5 years ago by anevilyak (previous) (diff)

comment:4 Changed 5 years ago by waddlesplash

OK, verified that this is a memory issue. The crash location is not consistent and the memory usage climbs to the same location always before crashing.

Is this still a bug due to the non-graceful handling of the out-of-memory error?

comment:5 in reply to:  4 Changed 5 years ago by anevilyak

Component: Applications/Debugger- General
Owner: changed from anevilyak to nobody

Replying to waddlesplash:

Is this still a bug due to the non-graceful handling of the out-of-memory error?

It is a bug, but not necessarily of any single component, as handling out of memory conditions isn't something that's generally tested all that much. The Debugger code itself takes care to verify all allocations for success and tries to gracefully fail in error cases, but there's little it can do if code somewhere in one of the kits or a 3rd party library that it relies upon doesn't do the same.

In any case, what's still not clear is if it's simply out of memory, or exhausting the address space. If the latter, then you're out of luck as far as debugging a Qt app without switching to a 64-bit build, which, as I previously pointed out is also necessary for other large libraries. From what I've seen of the size of the debug versions of the Qt libraries, that's highly likely to be the case.

comment:6 Changed 5 years ago by waddlesplash

Should I close this and create a new ticket called "Out-of-memory errors not handled gracefully everywhere"?

comment:7 Changed 4 years ago by waddlesplash

Milestone: R1Unscheduled

comment:8 Changed 6 weeks ago by waddlesplash

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