SIGSEGV message during debugging, but not consistently

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
ultrajunkie
Knows some wx things
Knows some wx things
Posts: 29
Joined: Sun May 30, 2021 10:11 am

SIGSEGV message during debugging, but not consistently

Post by ultrajunkie »

I have the following issue:

I am coding my application on 2 different machines, depending on availability. One is a PC with i9 and 64GB RAM, the other a notebook with an i5 and 16GB RAM, both with Windows 10 Professional. For compilation I am using Codelite as IDE and Mingw64 as toolset. wxWidgets version is 3.1.4 (but same behavior in 3.1.5).

My application is compiled in debug mode. Parameters (compiler flags etc.) are set identically (as far as I could determine). Without the debugger it runs on both machines without problems. I can also successfully debug on the notebook. However each time when starting the debugger on the PC I get a SIGSEGV error.

I was able to narrow the problem to the following code fragment:

wxString askstring = "Product not loaded. Load?";

if(wxMessageBox(askstring, "Load product", wxICON_QUESTION | wxYES_NO) != wxYES)
return;

When jumping into the wxMessageBox function, I find that the error seems to occur during a string conversion.

Any ideas?
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: SIGSEGV message during debugging, but not consistently

Post by doublemax »

Code: Select all

wxString askstring = "Product not loaded. Load?";
Where is this code line? If it's a global variable, that could be the problem.

Otherwise there is not much to go on. Can you provide a full call stack?
Use the source, Luke!
jpo234
Experienced Solver
Experienced Solver
Posts: 70
Joined: Tue Feb 25, 2020 11:34 am

Re: SIGSEGV message during debugging, but not consistently

Post by jpo234 »

ultrajunkie wrote: Sun May 30, 2021 10:36 am I was able to narrow the problem to the following code fragment:

wxString askstring = "Product not loaded. Load?";

if(wxMessageBox(askstring, "Load product", wxICON_QUESTION | wxYES_NO) != wxYES)
return;

When jumping into the wxMessageBox function, I find that the error seems to occur during a string conversion.
Does it ALWAYS happen there or did you just observe it once? My suspicion is that your heap got scrambled sometime before this and the bug manifests itself during random heap operations after the actual bug.

You might try to compile your code in Linux and see whether valgrind finds something fishy.
ultrajunkie
Knows some wx things
Knows some wx things
Posts: 29
Joined: Sun May 30, 2021 10:11 am

Re: SIGSEGV message during debugging, but not consistently

Post by ultrajunkie »

After some evenings I am a significant step further, but the result will not necessarily please the developers...

I have a command "Open File" in my menu. It calls without executing further code of mine the open file dialog. There I just need to wait long enough to get the SIGSEGV error without touching the dialog window. Previously I immediately selected a file and clicked "open" which was then misleading me to the assumption that it is the wxMessage function causing the issue.

Interestingly this only happens on one of the 2 computers. Running the program without debugger works also fine on both machines. And without the open command the window stays forever without any error. Therefore the error must be directly related to the file dialog.

The stack looks very poor (not much to get out):

0x00007ff7f8dbb7af in ?? ()

The debug log of the last action before the error:

DEBUG>>=thread-exited,id="45",group-id="i1"
=thread-exited,id="45",group-id="i1"
DEBUG>>=library-loaded,id="C:\\WINDOWS\\System32\\cscui.dll",target-name="C:\\WINDOWS\\System32\\cscui.dll",host-name="C:\\WINDOWS\\System32\\cscui.dll",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ff844e01000",to="0x00007ff844ecc030"}]
=library-loaded,id="C:\\WINDOWS\\System32\\cscui.dll",target-name="C:\\WINDOWS\\System32\\cscui.dll",host-name="C:\\WINDOWS\\System32\\cscui.dll",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ff844e01000",to="0x00007ff844ecc030"}]
DEBUG>>~"\nThread "
\nThread
DEBUG>>~"6 received signal SIGSEGV, Segmentation fault.\n"
6 received signal SIGSEGV, Segmentation fault.
DEBUG>>~"[Switching to Thread 22716.0x4254]\n"
[Switching to Thread 22716.0x4254]
DEBUG>>~"0x00007ff7f8dbb7af in ?? ()\n"
0x00007ff7f8dbb7af in ?? ()
DEBUG>>*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00007ff7f8dbb7af",func="??",args=[]},thread-id="6",stopped-threads="all"
Program Received signal SIGSEGV

To be honest, I'm a little bit lost at the moment. The only thing coming to my mind is starting debugging the file dialog which (I guess) is native Windows and therefore not available for debugging...
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: SIGSEGV message during debugging, but not consistently

Post by doublemax »

That's all not helpful.

Right now i'd say that either your build is somehow broken or you're doing something weird/wrong in your code which we can't see because you didn't show any code.

You need to either:
- create a minimal compilable sample that shows the issue (e.g. if it was really only related to the wxFileDialog, it should also happen in the "dialogs" sample that comes with wxWidgets. If it really does, there is something wrong with your build setup)
- get a proper backtrace

Do you do anything else when "Open File" is selected than showing the wxFileDialog? Can you show the code of the event handler?

Do you use threads anywhere?
Use the source, Luke!
jpo234
Experienced Solver
Experienced Solver
Posts: 70
Joined: Tue Feb 25, 2020 11:34 am

Re: SIGSEGV message during debugging, but not consistently

Post by jpo234 »

I'd bet a coin of small denomination that somewhere completely unrelated to the code where the error gets triggered, the heap got scrambled: a double free, write beyond an allocated memory block or whatever. I had a similar experience once, where a third party component accidently came with a binary library that didn't match the header they supplied us. The bug only happened when the library tried to set a flag at the end of one, rarely used structure. It drove me crazy...

Run your code with a memory checker like valgrind or Purify, I'll bet you the mentioned coin that it finds something.
Last edited by jpo234 on Fri Jun 04, 2021 11:48 pm, edited 1 time in total.
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7458
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: SIGSEGV message during debugging, but not consistently

Post by ONEEYEMAN »

Hi,
Is your software multi-threaded? Do you access GUI from inside a secondary thread?
Do you have any global external variables in the code (besides wxApp-derived object)?

Did you try to run it under the valgrind and see if it can spot something useful?

Other thatn that - try to create a MCE to reproduce the problem. The best way is to modify the dialogs sample provided with wxWidgets so that the modifications can be easily applied and tested.

Thank you.
ultrajunkie
Knows some wx things
Knows some wx things
Posts: 29
Joined: Sun May 30, 2021 10:11 am

Re: SIGSEGV message during debugging, but not consistently

Post by ultrajunkie »

Thanks to all of you so far for the various suggestions.

I found more astonishing stuff...

1. The same shit happens with the file save dialog.

2. I ran the gdb from a commandline and got the following:

1st warning
warning: onecore\com\combase\dcomrem\security.cxx(3057)\combase.dll!00007FF86F7D8FFC: (caller: 00007FF850F9823E) ReturnHr(1) tid(5a28) 80010117

2nd warning
[New Thread 18084.0x2ed4]
warning: CLR:(
warning: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
warning: )
warning: Rejecting native image because native image dependency C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll had a different identity than expected
warning:

Thread 15 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 18084.0x3bbc]
0x00007ff7f8dbb7af in ?? ()

3. And the best... this happens also with the dialogs sample:
Starting program: D:\Programmierung\wxWidgets-3.1.5\samples\dialogs\gcc_mswud\dialogs.exe
[New Thread 19448.0x56c0]
[New Thread 19448.0x5700]
[New Thread 19448.0x4508]
[New Thread 19448.0x36ac]
[New Thread 19448.0x5f1c]
[New Thread 19448.0x36d8]
[New Thread 19448.0x3c5c]
[New Thread 19448.0x1ab8]
[New Thread 19448.0x4730]
[Thread 19448.0x1ab8 exited with code 0]
[New Thread 19448.0x49b0]
[New Thread 19448.0x5df4]
[New Thread 19448.0x35c4]
[New Thread 19448.0x54a8]
[New Thread 19448.0x5b00]
[New Thread 19448.0x1b10]
[New Thread 19448.0x5eac]
[New Thread 19448.0x115c]
[New Thread 19448.0x5e5c]
warning: CLR:(
warning: C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
warning: )
warning: Rejecting native image because native image dependency C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll had a different identity than expected
warning:
[New Thread 19448.0x5cb8]

Thread 14 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 19448.0x5b00]
0x00007ff7f8dab7af in ?? ()

Somehow it looks like my WIndows installation is messed up. I googled already but didn't find a working solution yet. In the VS developer forum, Microsoft stated that this warning can be safely ignored, but this doesn't seem to be in reality. And I really wonder why the .Net framework should be required for wxWidget. Until now I thought it would set up directly on basic Windows functionality.
ultrajunkie
Knows some wx things
Knows some wx things
Posts: 29
Joined: Sun May 30, 2021 10:11 am

Re: SIGSEGV message during debugging, but not consistently

Post by ultrajunkie »

Forgot to answer some of the questions:

I have no programmed multithreading. The various threads are all wx related.
I am doing nothing special in the event handler either. Both "open" and "save" events are handled directly by wx. Zero lines of own code for those.

I have also no global external variables. A few utility routines are outside of the classes, but these are not used during the open or save call.
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: SIGSEGV message during debugging, but not consistently

Post by doublemax »

Please build and run the "dialogs" sample that comes with wxWidgets and check if it does the same.

Also: How big is your project? Could you easily just rebuild it with VS2019?
Use the source, Luke!
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7458
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: SIGSEGV message during debugging, but not consistently

Post by ONEEYEMAN »

Hi,
Which compiler do you use?
How did you build the library?
How did you build the application? Did you use exactly the same options?

Thank you.
ultrajunkie
Knows some wx things
Knows some wx things
Posts: 29
Joined: Sun May 30, 2021 10:11 am

Re: SIGSEGV message during debugging, but not consistently

Post by ultrajunkie »

@doublemax

I already tried with the Dialogs example - same error (see point 3 in my previous post).

I don't use VS2019, and I think that the IDE doesn't have an influence since I am using gcc/g++ which is independent from CodeLite.

Apart from that, on the other computer the application runs fine within CodeLite with gdb. Here is the log from the file dialog loading phase on the other machine (notebook):

[New Thread 15748.0x3b80]
warning: onecore\com\combase\dcomrem\security.cxx(3057)\combase.dll!00007FF9CCEC8FFC: (caller: 00007FF9A189823E) ReturnHr(1) tid(3b80) 80010117 Auf den Aufrufkontext kann nicht zugegriffen werden, nachdem der Aufruf beendet ist.
[New Thread 15748.0x2cc8]
[New Thread 15748.0x44fc]
[New Thread 15748.0x3f3c]
[New Thread 15748.0x4318]
[New Thread 15748.0x2da0]
[New Thread 15748.0x5d4]
[New Thread 15748.0x45f8]
[New Thread 15748.0x2df8]
[New Thread 15748.0x3f50]
warning: onecore\com\combase\dcomrem\security.cxx(3057)\combase.dll!00007FF9CCEC8FFC: (caller: 00007FF9A189823E) ReturnHr(2) tid(3b80) 80010117 Auf den Aufrufkontext kann nicht zugegriffen werden, nachdem der Aufruf beendet ist.
[Thread 15748.0x2df8 exited with code 0]
[New Thread 15748.0xb94]
[New Thread 15748.0x473c]
[New Thread 15748.0x2888]
[New Thread 15748.0x3724]
[New Thread 15748.0x76c]
[New Thread 15748.0x574]
[New Thread 15748.0x3178]
[New Thread 15748.0x2d5c]
[Thread 15748.0x2d5c exited with code 0]
warning: onecore\com\combase\dcomrem\resolver.cxx(2283)\combase.dll!00007FF9CCEA21BE: (caller: 00007FF9CCEA4EBE) ReturnHr(3) tid(3970) 80070005 Zugriff verweigert
warning: onecore\com\combase\dcomrem\resolver.cxx(2491)\combase.dll!00007FF9CCEA4EE6: (caller: 00007FF9CCEA1A05) ReturnHr(4) tid(3970) 80070005 Zugriff verweigert
warning: onecore\com\combase\dcomrem\resolver.cxx(2283)\combase.dll!00007FF9CCEA21BE: (caller: 00007FF9CCEA4EBE) ReturnHr(5) tid(3e90) 80070005 Zugriff verweigert
warning: onecore\com\combase\dcomrem\resolver.cxx(2491)\combase.dll!00007FF9CCEA4EE6: (caller: 00007FF9CCEA1A05) ReturnHr(6) tid(3e90) 80070005 Zugriff verweigert
[Thread 15748.0x3088 exited with code 0]
[Thread 15748.0x3b80 exited with code 0]
[New Thread 15748.0x624]
[Thread 15748.0x624 exited with code 0]
[New Thread 15748.0x3250]
[Thread 15748.0x3250 exited with code 0]

@ONEEYEMAN
I am using mingw64 in the version x86_64-8.1.0-release-posix-sjlj-rt_v6-rev0
Library and application are built the same way: shared + debug
ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 7458
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: SIGSEGV message during debugging, but not consistently

Post by ONEEYEMAN »

Hi,
I resume both machines have the same version of Windows with all latest updates?
Did you by chance build the library as MONOLITHIC?
What happen if you grab the binary from the working machine and try to run it on the machine where the original fails?
What happen if you switch it -copy from the non-working to working and try to run?

Thank you.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4193
Joined: Sun Jan 03, 2010 5:45 pm

Re: SIGSEGV message during debugging, but not consistently

Post by PB »

Firstly, wxWidgets does not use any .NET stuff.

Out of curiosity I tried to reproduce the issue with the dialogs sample but I could not.

I think as the error indicates, the other machine is messed-up somehow and the issue is not with wxWidgets.

I assume the build setup and parameters are exactly the same on both machines and you also have all required DLLs (wxWidgets, GCC) inside the folder with the executable on both machines without relying on them being found somewhere in the PATH.

EDIT
I forgot to mention that some shell extensions may cause similar issues. Did you try file accessing the file open dialog (I am assuming it is the new Vista-style one) in applications such as notepad?
Last edited by PB on Sat Jun 05, 2021 6:21 pm, edited 1 time in total.
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: SIGSEGV message during debugging, but not consistently

Post by doublemax »

I don't use VS2019, and I think that the IDE doesn't have an influence since I am using gcc/g++ which is independent from CodeLite.
Now that we know that the "dialogs" sample shows the same issue, it must be either your build or your machine.

Therefore, if you build it with VS2019 and it works fine, we know it's your build setup.
If it crashes, too, it's your system.

Please double check that you don't have multiple MinGW toolchains on your system and that you're not mixing include files and/or libs from other wx installations.
Use the source, Luke!
Post Reply