Le 1 avr. 2010 à 16:00, Fritz Anderson a écrit :
I tried with -fstack-protector-all, but I can't see any improvement. I get the same behavior and the same messages, and the callstacks shown by GDB sometimes are empty or incomplete.
I assumed the callstacks would be from the thread whose stack is too small but it's not always the case.
Le 1 avr. 2010 à 16:09, Paul Sanders a écrit : You could also try writing something like this to see if the
effect it creates in GDB mimics what you are seeing in your app:
void black_hole (int depth)
{
black_hole (depth + 1);
}
I tried this with a Cocoa sample application and I get the same messages, the main difference is that the behavior is consistent with each run instead of having random crash points: " Running… Program received signal: “EXC_BAD_ACCESS”. [Switching to process 9198] [Switching to process 9198] sharedlibrary apply-load-rules all Warning: the current language does not match this frame. warning: Unable to restore previously selected frame. No memory available to program now: unsafe to call malloc warning: check_safe_call: could not restore current frame
warning: Unable to restore previously selected frame. Data Formatters temporarily unavailable, will re-try after a 'continue'. (Not safe to call dlopen at this time.) "
Xcode also displays a message box because it takes about 30 seconds to create the "black_hole" callstack, eg: "Loading 16382 stack frames... (21%)". Adding -fstack-protector-all to "Other C Flags" doesn't help, I still see the same behavior.
Thanks for your answers!
|