rwm

heya!

ive been running into very strange bugs that seem to be originating from teh use of std::cout...

basically ive written a series of file parsers (which are used for a plugin using the maya API), and when i run the code independently from maya API the code runs fine, no problems whatsoever, but when I compile with the maya code maya keeps crashing with a fatal error. in the maya code i have put in couts in certain parts of the code, so well being me i put in some debug couts and the code suddenly started running fine so im like wtf! then i think maybe its got to be something to do with flushing the stream, so i simply remove the debug cout calls and replace with a call to cout.flush() and just as i expected the code runs fine...

i know this is not a maya API forum, but maybe someone has insight into why this might be causing problems...

has anyone run into a similar problem?

looking forward to a response!

thanks!

grumpy

Like many problems that involve a program crash, the real cause of your problem is probably pointer molestation (dereferencing a NULL or uninitialised pointer, falling off the end of an array, etc etc). One side effect of adding additional operations (eg output to cout) is changing memory layout of your program -- and, when a pointer is molested, the effected memory can change and therefore the visible effect can change.

Another symptom -- which looks somewhat different but actually has the same root cause -- is a program that crashes until it is recompiled with different compiler optimisation settings, and then it doesn't crash. Again, the reason for the changing symptom is that changing compiler settings change layout of memory used by your application. The cause of the original crash, however, remains.

I would bet that the problem is unlikely to be related specifically to any operations involving cout. iostream functions and objects are pretty commonly used so, if you are using a mature compiler/library, most bugs with will have been ironed out by now.

It's possible that the problem is one of the functions in the MAYA API, but I suggest looking at your own code before blaming third-party code. For example, file parsers often do some form of memory management (eg creating a linked list to represent a parse tree,and later traversing that list) so there are many opportunities for mistakes with pointers.

rwm

hey grumpy! thanks for the reply! ok, it does make sense that its probably a memory bug(s) in my code, i wouldnt blame the maya API, its most likely something wrong in my code... i had no idea that cout would change memory layout... but ive posted a new thread about overloading new/delete so i can track down the bug... hope you can help me with that!

thanks!

grumpy

Any operation that changes behaviour of your code can, as a side effect, change memory layout of your program. Particularly if the change of behaviour involves use of any memory buffers. And cout does buffered I/O......

I/O generally involves fetching the value of a variable. That can change ability of a compiler to do some optimisations. For example, some common optimisations are concerned with eliminating unused variables or intermediate results of calculations. It is more difficult for a compiler to eliminate a variable or value that is actually output. Elimination of variables can change the basic memory layout of your program as well as order of execution of instructions.

Overloading new/delete is probably not the way to find your problem. That will only find problems that are related to incorrect usage of new/delete (eg memory leaks). There are lots of ways to molest a pointer that do not involve usage of new/delete at all. For example, traversing a linked list and going one too far will not involve any usage of new/delete. Nor will dereferencing an uninitialised pointer.

rwm

hey Grumpy! thanks for the reply!

mmm ok. so what would be the best way to find the bug? use a debugger? ive tried using gdb on linux, but the minute i go step the application crashes

so my problem is probably related to out-of-bounds access then?

grumpy

Your problem is almost certainly pointer molestation. One type of pointer molestation is out-of-bounds access.

First, the obligatory nag: the best way is to understand your code (i.e. not hack it, and do things by trial and error) so you avoid the problems in the first place.

The thing to remember is that a program crash typically results from a series of events. For example;

1) Some code molests a pointer and corrupts some data;

2) Some other code accesses that corrupt data, and changes some other data as a result.

3) Step 2 may be repeated many times, particularly if the data being corrupted happens to be another pointer or a variable used as an array index.

4) Because of this your program does things that were unintended and, eventually, one of the unintended effects is detected by either the operating system or a library function. When that happens, your program is forcibly terminated (eg the operating system sends a signal indicating a segmentation fault to the application).

5) Your application terminates.

The thing is, running a debugger and stopping when the crash occurs, means you START examining things at step 4. If you step forward from that point, all you will see is the process of your application terminating. That gives you no information about why it is terminating: the process is already underway. So, rather than stepping forward from a crash, you need to reason out how to get back to the earlier steps that actually CAUSED the crash.

You can use a debugger to find a problem, or analyse your code to find a problem, but you need to work backwards. When a crash occurs, there is no point in stepping forward in the debugger: the damage has already occurred, and the cause is history. Firstly you need to find the line of code where the crash is occurring. Rather than stepping from that point (which will simply complete the process of terminating/crashing your application) you need to identify what memory or variables are being accessed when the crash is triggered. Then you need to work out why that memory or those variables are being accessed and what the values are supposed to be (both before and after the offending code, assuming things are OK). Odds are, one of the values or variables will be different from what they are supposed to be. The thing to remember now is that some code, executed before symptoms of the crash became evident, probably overwrote those variables. So stepping forward from a crash is pointless. Instead you need to exit the debugger, and restart it (i.e. run the application with the debugger from the beginning) and step through until the offending variables are overwritten. Then you need to repeat the process, until you identify the root cause of the problem.

rwm

hey grumpy!

thanks for the reply! well i actually did start doing that, but i need to learn more about the debugger first, i.e. how to debug shared libraries (so)...

thanks for the suggestion!