0

I'm developing an audio application that can let you create and play music with text files for 32-bit Windows. I'm using C++ as the language and TDM-gcc 4.8.1 (sjlj) as my tool chain. The libraries I use are - SFML, portaudio and libsndfile.

APPCRASH error message

I started getting this APPCRASH error when I close the app. And I noticed that this error happens only when I open a file open/save dialog and then try to exit the app. Multi-threading might have something to do with this because I'm opening file dialogs on separate threads with SFML's Thread class. (so that the main window can keep updating on its own) I imagine portaudio also probably uses its own thread to handle its own buffering and callbacks?

Since the program compiles just fine and I get no errors then, it's hard for me to know what's causing this. I've been changing and commenting out many parts of the program but with no luck... The exception code c000374 supposedly means 'heap corruption', but what does that really mean? What are the common causes? What can I do to narrow down the possible causes?

And at another time, I got this message:

Another error with physical addresses

But how can I know which address corresponds to what part of the program? (or which data or class) Is there a good debugger that can map out class, method and variable names to physical addresses that the executable uses?

morezoom
  • 101
  • 3
  • 7
  • Fire up your program in GDB. Do what you normally do to trigger the crash. When it crashes, use GDB to [inspect the stack trace with the bt command](https://sourceware.org/gdb/onlinedocs/gdb/Backtrace.html). Use the trace information to place breakpoints and variable monitors accordingly. Run program again in GDB to gather further information. – user4581301 Jan 20 '16 at 01:45
  • The tools discussed here http://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows may help, for example Dr memory. – J.J. Hakala Jan 20 '16 at 01:45
  • Are you using an IDE? it may be able to automate some of the debugging grunt work for you. – user4581301 Jan 20 '16 at 01:47
  • 1
    Notice the part of the second dialog where it offers to open the program in a debugger for you? Just use that. – MrEricSir Jan 20 '16 at 02:06
  • Thank you for all your comments! I went ahead and did the back tracing with GDB, and got the following: #0 0x7794e3c6 in ntdll!RtlInitUnicodeString () from C:\Windows\SysWOW64\ntdll.dll ... Backtrace stopped: previous frame inner to this frame (corrupt stack?) Maybe this suggests the error might have to do with something with strings? No, I'm not using an IDE, so you're right, perhaps using Code::Blocks etc. might help. Thank you for the suggestions for the tools, also - I will look into them right away! – morezoom Jan 20 '16 at 02:55

0 Answers0