ssbssa / heob

Detects buffer overruns and memory leaks.
Boost Software License 1.0
156 stars 25 forks source link

Crash when using heob on Qt 5.11 application #7

Closed mitchcurtis closed 6 years ago

mitchcurtis commented 6 years ago

heob-crash.zip

  1. Build the attached application with Qt 5.11 (betas are currently available in the online installer).
  2. Run it through heob in Qt Creator.
  3. Click the "Load" button in the application's window.
  4. Hit "Off" then "On" then "Clear".
  5. Close the application. Heob should crash. You might need to try steps 2 to 5 a few times before it crashes.
ssbssa commented 6 years ago

Interesting, I havn't had heob crashes in quite a while, so I hope i can reproduce once I've downloaded/installed the 5.11 beta.

ssbssa commented 6 years ago

Sadly I can't reproduce your crash. Are you using 32 or 64bit, Debug or Release build? And is it really heob32/64.exe itself that's crashing, not the heob-crash.exe?

mitchcurtis commented 6 years ago

Sadly I can't reproduce your crash.

Did you try a few times? It didn't crash for me the first two times, but on the third try.

I am also able to reproduce it with Qt 5.9.4, actually.

Are you using 32 or 64bit, Debug or Release build?

64 bit debug build of the application being run under heob. For heob itself I'm using the 64 bit binaries that you have provided.

And is it really heob32/64.exe itself that's crashing, not the heob-crash.exe?

It says "heap observer has stopped working" in the error message box, and "Heob: Heob stopped unexpectedly." in Creator's issues pane. I am yet to see the application itself crash.

ssbssa commented 6 years ago

Did you try a few times? It didn't crash for me the first two times, but on the third try.

Yes, more than 20 times.

64 bit debug build of the application being run under heob. For heob itself I'm using the 64 bit binaries that you have provided.

I guess you mean the heob-2.0.7z.

It says "heap observer has stopped working" in the error message box, and "Heob: Heob stopped unexpectedly." in Creator's issues pane. I am yet to see the application itself crash.

Very weird. Does it happen with the heob executable you built yourself as well?

ssbssa commented 6 years ago

@mitchcurtis Can you please attach the generated leaks.xml after a crash happened? It might give me a hint where the problem is.

mitchcurtis commented 6 years ago

@ssbssa where is it? I don't see it in the source or build directory, so maybe it wasn't generated on account of the crash?

mitchcurtis commented 6 years ago

Does it happen with the heob executable you built yourself as well?

Yes.

Oh, I was looking in the wrong place. Here's leaks.xml using a self-built heob. leaks.zip

ssbssa commented 6 years ago

Here's leaks.xml using a self-built heob.

Looks like it crashes before any leak-data is written is written, so sadly this doesn't narrow it down by much.

Have you tried it with a debug build to see where exactly it crashes?

mitchcurtis commented 6 years ago

That's a good point; you fixed that build issue... so after doing the stuff mentioned in https://github.com/ssbssa/heob/issues/11#issuecomment-379460909, I attached to a debug build of heob in Creator:

1 printStackGroupXml  heob.c   2426 0x7ff6dfe3ad17 
2 printLeaks          heob.c   2696 0x7ff6dfe3a253 
3 mainCRTStartup      heob.c   4306 0x7ff6dfe3694a 
4 BaseThreadInitThunk KERNEL32      0x7ff9d33c1fe4 
5 RtlUserThreadStart  ntdll         0x7ff9d5b1f061 

Locals pane contents:

    Locals      
        a   <not accessible>    allocation*
        alloc_a <not accessible>    allocation*
        alloc_idxs  <not accessible>    int*
        alloc_q 0   int
        childSorted_a   0x0 int*
        child_a <not accessible>    stackGroup*
        combSize    <not accessible>    unsigned int64
        ds  @0x66ec97f3d0   dbgsym
        i   <not accessible>    int
        idx <not accessible>    int
        leakTypeNames   "lost"  char*
        mi_a    @0x1e2ee989ee0  modInfo
        mi_q    21  int
        minLeakSize 0   unsigned int64
        sg  <not accessible>    stackGroup*
        tc  <not accessible>    textColor*
        threadNameIdx   <not accessible>    int
        threadName_a    @0x1e2eeb8dd80  threadNameInfo
        threadName_q    2   int
        unnamedIdx  <not accessible>    unsigned int
        xmlLeakTypeNames    @0x66ec97eaf8   char*[5]
        xmlRecordNum    0   int
    Inspector       
    Expressions     
    Return Value        
    Tooltip     

The message was:

Stopped in thread 0 by: Exception at 0x7ff6dfe3ad17, code: 0xc0000005: read access violation at: 0x1986001187b, flags=0x0 (first chance).

mitchcurtis commented 6 years ago

If you have a patch to debug it further, I can apply it and give you the output.

ssbssa commented 6 years ago

Thank you, I was finally able to reproduce with this additional information.

I'm thinking of creating a new release because of this fix (and the few feature requests I implemented since the last release).

mitchcurtis commented 6 years ago

Good to hear!

+1 for a new release. :)