Crash in release?

Audio Plugins
1


Hi,
My plug runs fine both in debug and release on most systems (mine and some user's, from 10.7 to 10.9).
But a user that is on 10.7 reported that it was crashing when the GUI opens (the plug is loaded fine before that).
The thing is that a debug build would not crash on is system, only the release one.
Any idea what could be the cause of that (i.e. crash in release, but only on a particular mac 10.7) ?

(the jucedemoplugin works fine for him, both in debug and release, and I got the same buils settings)
 

2

Check for any uninitialized variables.

Rail

3

+1

4

ok, I'm still looking at it .. but it's madness to spot it out when I can't reproduce.

and in fact it's not crashing when the gui opens. the AU scan goes fine, but it then crashes during the construction of the processor part when the user insert the fx... weird. so I guess that must be related to some corrupted memory..?

The fact that it crashes only on the mac of 1 user, and that it never crashes elsewhere isn't weird?

5

In the Apple LLVM 5.1 Warnings - All languages sections of your project settings enable warnings for Uninitialized Variables.

If it still fails, then use a FileLogger to find where it’s failing… I’d look around registerFormat() in juce/modules/juce_audio_formats/format/juce_AudioFormatManager.cpp

Rail

6

ok,I need a guru here :) I did intensive log in there, so the code is :


const float temp = chunkSize * 0.5f;
Logger::writeToLog ("fadeSize = " + String (fadeSize));
Logger::writeToLog ("temp = " + String (temp));
fadeSize = static_cast <int> (std::floor (temp));
Logger::writeToLog ("fadeSize = " + String (fadeSize));

fadeSize is an int. (static_cast or just (int) lead to the same result.  

the log I got is :

fadeSize = 1
temp = 110.5


and it crashes at the next line. So what could possibly be wrong in that std::floor call ?

in the build settings I got LINK_WITH_STANDARD_LIBRARIES to yes.

Any idea ?

 

7

What happens if you use a ‘regular’ cast?

also try:

The code looks fine which may indicate that something else is stepping on the memory space… check for any out of bounds issues.

Rail

8

thanks yes, you're right, must be a out of bound. hum... gonna re-check all the code again..  

9

well, I replaced to static_cast <int> (std::floor (temp));

by : 

 (int) (temp);

and now the plugin crashes much later, in the process function.

Sounds like something crasy, I can hardly beleive there's such a corrupted memory issue in my code when nobody had a crash like that before.
Could that possibly be something wrong on the user's system?

10

I’ve had (someone else’s) code (of course ) which worked fine on OSX 10.8.5 but crashed on 10.9… so there may be slight differences on your user’s system which exposes an issue you don’t see on yours… path names, language, drivers, etc… but it’ll usually come down to a bad pointer or memory corruption issue due to an out of bounds issue.

I wouldn’t assume there’s something “wrong” with the user’s system.

Rail

11

yes, right. but as except for his 10.7 it runs fine for everybody's else 10.7/8/9/10 it just drives me crazy :)
 

12

BTW I find that also compiling with Visual Studio and running on Windows will sometimes expose small warnings I don’t see when compiling on OSX.

Rail

13

BTW I find that also compiling with Visual Studio and running on Windows will sometimes expose small warnings I don't see when compiling on OSX.

Rail

yes, me too usually.

But with /W4 warning level and SDL on I got no warnings. There's no uninitialized variables that popups, or nothing wrong at all that I could find in my code for now. 

with -Wall I get tons of warning, but they are unimportant ones it seems. But that's quite a lot of work to read that all. Let me know if you got some good warning settings recommendation.

14
with -Wall I get tons of warning, but they are unimportant ones it seems

There are no unimportant warnings, even if you know some code is safe it's always best to refactor it to not trigger warnings. If nothing else, it makes new warnings difficult to spot.

I'm guessing you have a heap corruption somewhere in your program that just happens to get triggered at this point. The source could be anywhere.

15

There are no unimportant warnings, even if you know some code is safe it's always best to refactor it to not trigger warnings

So you care about those thousands of " bytes padding added after data member", "unreferenced inline function has been removed", 'JUCE_MAC' is not defined as a preprocessor macro,  enumerator 'X' in switch of enum 'Y' is not explicitly handled by a case label", and you refactored the juce lib to get rid of them ? ;)

16

Absolutely. If you do get warnings in JUCE code let Jules know as he'll fix them. All of the warnings you listed there could be very relevant. Are you on Windows? Do you have the warning numbers for those warnings as I'd like to look them up before saying exactly what's causing them to appear.

We compile all our projects with the highest warning levels we can find so if we're missing some I'd like to add them ;)

One of my biggest annoyances is when you can't get some warnings in certain compilers.

17

well, yes, some might be important within the 20000 ones, it's hard to read that all :)
but most of them just inform you about something you don't really care. you won't get rid of 'function not inlined' or 'unreferenced inline function has been removed'.

just set the highest warning level in visual -Wall. you'll have C4820 C4626 C4514 C4668 C4625 C4061 and others...