Greg Parker wrote on Wednesday, January 28, 2009 4:22 PM > On Jan 28, 2009, at 10:33 AM, Karan, Cem (Civ, ARL/CISD) wrote: > > First off, I know this question is going to the wrong list, > but I have > > NO idea which list would be best. If anyone wants to jump > in and tell > > me a better list, I'll gladly move there. > > > > Background: > > I have an application that is working very, very hard to drive me > > insane. It is multithreaded, lazy, and has my broken attempt at > > trampoline code. Now, it crashes once in a while, but I'm not sure > > what the trail of broken bits are that causes the crash. If only I > > had a way of instrumenting every single entry and exit of each > > function, I could log it all… which is exactly what -finstrument- > > functions does. > > You'll likely get better results from dtrace than > -finstrument- functions. DTrace can be programmed to act on > function entry or exit for all functions in a specified file. > (DTrace experts: this is your cue to chime in.)
I thought DTrace was primarily statistical in nature, right? Won't -finstrument-function work better in my case because it is guaranteed to be called each time? Meh, I have no idea; I've never used it before, just Instruments, and not much at that. > Be warned that any instrumentation tool is likely to perturb > your bug away, if it is in fact a problem with multithreading > or code generation. I KNEW I'd seen a great name for this somewhere! http://en.wikipedia.org/wiki/Heisenbug#Heisenbug Yes, I'm familiar with them, and that is part of the reason for running the traces. I'm hoping that with enough traces I'll figure out why I'm having problems. I figure that by running diffs on all the traces, I'll start finding commonalities between them, which will give me a clue as to what to look for. > > For those of you that don't know about it, when you > compile your code > > using -finstrument-functions, just after the entry point of each > > instrumented function the function > __cyg_profile_func_enter() will be > > called, and __cyg_profile_func_exit() will be called just before > > function exit. You define those functions as you wish. > > > > The tricky part is that there are certain functions that > must not be > > instrumented like that, so you need to set the attribute > > no_instrument_function on those functions. In my case, I > want to run > > some startup code before either of those methods ever get > called. I > > put my code into main(), but, IIRC, there is some function > that gets > > called before main() does. If that is a library function, I'm OK > > since __cyg*() won't get compiled into anything I don't have the > > source for, but if gcc is generating some code that calls __cyg*() > > before I get the chance to do the setup, I'm going to > > have another crash. So, is there anything called before main()? > > What about just before main() returns? > > +load methods and static C++ constructors are obvious examples of code > run before main(). I hadn't thought of those. That would explain a great deal though. > For testing purposes, you could add a flag that's set after > your prep work is complete, and check it in > __cyg_profile_func_enter. You could even do the prep work > inside __cyg_profile_func_enter if the flag isn't set yet. Yeah, I just tested that, and it works well. I'd like to find a way of registering a callback that is guaranteed to be the last function called in the program, but there doesn't seem to be a way (registering with atexit() doesn't work; there are a lot of functions called afterwards, and, although not actually necessary for what I'm doing, I'd like to see what they are) Thanks, Cem Karan _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
