-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExcHndl.dll can't print the crash call stack under Windows 7 #71
Comments
This is likely related to #55, but perhaps there's more going on as I think that issue was fixed, and the versions/symptoms reported above don't line up exactly. An easy experiment to make here is to try drmingw-0.9.x's drmingw.exe/mgwhelp.dll/exchndl.dll with drmingw-0.9.1's dbghelp.dll symsrv.dll. This will enable tease apart whether the regression is the newer dbghelp DLLs, or some code change in drmingw itself. |
Hi, thanks for the response. I just tried your mentioned experiment.
So, it looks like the regression is inside drmingw itself? |
I did some further test, I keep the file: Then, I have using the My guess is maybe the GCC has changed and your are using the mismatched libbfd library, and this library can't decode the line information? When I test a dll with debug information or without debug information, if I got the call stack, I see the call stack is the same, so my guess is that the debug information is not used by drmingw? |
Thanks for those experiments. We no longer use libbfd. We use libdwarf instead. But I agree with your assessment -- the problem is not using symbols. Looking at the changes in range, my suspicion goes to bd80ec2, namely the Could you please attach a zip with an executable compiled with C::B which I can easily reproduce the issue using addr2line? It would save me time and quickly focus on the issue. |
Hi, I did a simple test for the latest version 0.9.5 1, I install the drmingw through the pacman command under msys2's mingw64
2, I create a simple console project under C::B, the content is just the file named "/mingw64/share/drmingw/sample/sample.cpp" 3, I set the drmingw.exe as the jit debugger, and run the built exe file, when it crashed, the drmingw.exe jump out, and I see it has line information in the drmingw.exe's report window.
This means drmingw can catch the call stack and print the line information. What I reported issue is that a plugin crashed inside C::B, and drmingw can't catch the crash. I guess the difference is that when running the sample from "/mingw64/share/drmingw/sample/sample.cpp", it is a single thread application. Which my original reported issue is that the crash happens in a worker thread. I will try to create a crash app which the crash point is in a worker thread. |
I made another example, which I make the crash in a worker thread:
when I run the generated app, I got the correct line and call stack in the drmingw gui, see below:
The interesting thing is: if I "rename" the main.cpp to "main6666.cpp", and I see drmingw can't find the main.cpp file, and the crash report shown in drmingw gui looks like below, though the line information is still there.
Note that all the test is done in Windows 7 64bit and the msys2's latest 64bit mingw64 compiler, and the drmingw 0.9.5 . Which means I can't reproduce the issue (a plugin crashed the C::B). I really don't know how to give more tests, because reproduce my original issue involving the whole C::B and the testing C::B project is too complex. But I can't reproduce the issue in a simple single thread or multi thread application. |
I see. If the remaining C::B issue is specific to multiple threads, then this is a known limitation, as mentioned on #54 That said, nothing changed in this respect since version 0.9.1. So I don't see how come 0.9.1 worked, but now it does not... |
So it seems the issue is more subtle than any reasons advanced so far. Ideally I'd reproduce the issue myself with C::B and investigate the issue. I tried to download C::B release/nighly binaries, but neither seems to contain any debug symbols. Getting C::B to crash is easy -- patching the Another solution is for you, @asmwarrior, to git bisect drmingw history, while replacing dbghelp.dll and friends with 0.9.1's DLLs, and figure out which commit broke C::B. If building drmingw is tricky, you can always temporary clone DrMinGW to a personal repos, and then push tags for every commit to test, and download the binaries from GitHub built through GitHub Actions. |
Hi, jrfonseca, thanks for the response. Building C::B is not easy, it need a self built wx library, and you have other tweaks here and there. I think the issue can be divided to parts: 1, the C::B crash can't be caught, I mean 0.9.1 can catch the crash, but the later version can't catch the crash. About the github action, I haven't used this tool before, I just noticed that you have tag the 0.9.6 in your git repo, and I see github action was running, but I really don't know how to download the generated file(If I'm correctly, it called the artifact file). Thanks. |
I found a very interesting thing, I was set the drmingw 0.9.5 as a jit debugger, and under C::B I was still use the exchndl.dll version 0.9.1. Test1: Test2: |
While, I did another test: I just replaced the exchndl.dll file (in the same folder as codeblocks.exe) from 0.9.1 to 0.9.5, and I make the same crash as in Test2, the result is: I don't see any thing written to the RPT file, which means the embedded exchndl.dll 0.9.5 does not work, but the jump out jit debugger 0.9.5 windows shows the call stack and line information correctly as the Test2. |
It looks build drmingw is a bit hard for me. I clone the repo and update all the submodules. Now, if I run cmake under msys2's mingw64 shell, I first got the "WinDBG" not found error. So, I comment out the line in the CMakeLists.txt
Now, here comes another issue:
I really don't know how to fix this issue, it looks like I have to enable the option "POSIX_THREADS" This make the local building of drmingw a bit hard. BTW: I just read this: https://github.com/jrfonseca/drmingw/blob/master/BUILD.md It said the windbg is recommended, what does recommende mean? is it optional? EDIT:
|
Hi, I think I have found the reason of this issue. I just add many I first found that the crash is correctly found by the event handler. And later, I found that the report file is wrong here.
When this message jump out
I see the content of the messagebox is:
So, you see, the expected log file name should be:
That's why the report file does not contains the crash report. |
This is my test code to see where the problem is:
It looks like this line:
is not correct. In my test code
What I guess is that we need a
Anyway, I think the code is still complex to understand. |
With the above mentioned changes in the source file I'm testing the latest git master, which shows the version is 0.9.6. |
@asmwarrior, apologies for the silence. I'm currently abroad and have no spare time. Thanks for the further investigation and updates. At a glance, it makes sense. I thought I had a test to prevent this, but I now realize my tests all call |
OK, Thanks for the reply. I'm not sure why using a byte array is OK here, but from my point of view, a string or wstring is better to handle those file path find and replace task. It looks strange that this issue happens for at least several years, and it looks like no other guys see or report it. Another thing is that Code::Blocks ship this tool, and I hope you will release a new version drmingw, so that we can update our old 0.9.1 version. Thanks. |
@jrfonseca any progress about this issue? |
Fixed now. I'll make a new release shortly too. |
Hi, we use the drmingw-0.9.1-win64(exchndl.dll) in Code::Blocks(we build it from Msys2/MinGW GCC) to catch/report the crash. Thanks for the great tool.
While, we found some issue when using this tool under Windows7 (64bit).
The first thing is: Under Windows 7, the latest usable version is 0.9.1. I did some test:
The second thing is: please note that when using drmingw-0.9.1-win64, we can't see the line information is printed when the full call stack is reported. (The dll and exe were all containing the debug information)
The full discussion is here in our Code::Blocks forum:
error alert message when using ThreadSearch Plugin
Thanks.
The text was updated successfully, but these errors were encountered: