Debugger crashes while debugging a Qt app

[waddlesplash]

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.

[waddlesplash]

Backtrace of the crash.

[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.

[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.

[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.

[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?

[anevilyak]

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.

[waddlesplash]

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

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed