Kiran Divakaran wrote: > Hi All, > > I have a strange problem . One of the functions in the application we use is > dumping core. > > Once we put fprintf inside the function and traced through the file , the > core stops appearing . So the only change that was done to the file was to > > put fprintfs inside it that to debug it and trace through the last function > which was appearing on the core stack. > > Apparently this is preventing the core from being dumped on SunOS. > > Also there are strange things like if the fprintf is commented / added at > particular points in the function then the core issue reappears. > > Is it got to do with the stack being in a inconsistent state and calling a > fprintf restores it unloads it in some way and things get back to working. > > The stack should behave the way it is supposed to as a part of the Operating > system and would be the last thing to suspect it. > > But there have been issues like in the past where HP/SUN had genuine bugs in > their OS and later provided patches when raised with them. > > Is that the situation here or do we need to probe something on our > application front. > > Please let know your inputs on the same or rather explain this issue > technically as to what might be happening ? > > > Regards, > Kiran
Sounds like a buffer overflow _elsewhere_ in your code (or the underlying library, but that is unlikely) that is causing the crash - if you step outside memory boundaries of an array in a totally unrelated function, the program can crash anywhere else (usually when the memory allocator goes to allocate more memory and a memory check is done, it'll crash right then). Adding one-liners like printf() that cause such crash bugs to vanish makes these types of bugs very hard to track down (the bug still exists BUT you've shifted memory and code around such that it won't happen again on YOUR computer). My suggestion is to make the crash bug happen and keep the code that way until you find the actual bug and squash it. You could try ltrace or strace to track the logical paths of the code, but that may or may not help. Sitting there staring at 'gdb' all day could help too. Set a breakpoint on the code and step through line-by-line and stare at each variable until you find the problem. Hopefully your code isn't too lengthy. This is a painful process and will likely take all day long even with a good IDE managing the interaction with gdb. If it doesn't crash with debugging information compiled in, that will make it much more frustrating and take even longer. Too bad you are on Sun. VC++ 2008 has the best debugger in existence. Unfortunately, it only runs on Windows. If your code can port cleanly (i.e. you aren't doing anything particularly OS-specific), then you might consider locating a Windows box with VS on it and see what the VC++ debugger has to say. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/
