Hello,

my C code crashes on MIPS issuing a SIGBUS. Where i am facing the problem (well, its common to everyone)is to find out why it is crashing. The point where it is crashing is a malloc (X), where X is some int value say 1318. The problem is not actually in malloc and its somewhere before it, where?.... this i need to find. Please note that i am cross compiling the code for mips on my x86.

So far i have tried with these options:
option what happened
------- -------------
1. gdbserver - did not helped as it showed stack corrupted.
2. core dump - the gdb itself crashes with a core dump
3. glibc's backtrace()/backtrace_symbols - did not help . (On googling it was found that on mips, its not supported yet)
4. manual printfs/syslogs - proceeding with this but this seem to take me eternity.

here is what is my code sequence:

A----------B-------------C R A S H

the code starts from A and crashes at C, and C is the malloc(X). B is the region (region!!! because i its not a single line/statement causing the crash)of code which toggles CRASH. It was found that if a malloc(500)(i am not sure whats so magical about 500 i just found it out in number of iterations) is done between A and B, crash doesn't happens.As far as B is concerned, here there is no dynamic memory being taken from the system and all the pointer manipulations seem fine enough.

the purpose of my query is to ask for your valuable suggestion in terms of other options/steps/information, anything (logical or not) would be appreciated. Can any body point me to some code which i can use to to see what the state of processor resistors is at the time of crash?

I'm hoping that others will come along with spiffy tools for you to use to find out why your heap (or maybe stack) is corrupted. But I have had problems like this in situations where no such tool is available.

What I've usually done is to make the program as simple as it possibly can be, and still show the problem. Make A, and B, and everything between A and B, and everything between B and C, as simple as possible. Start ripping out code. If you rip out too much, so the program starts to behave, put some of the code back. If the code you're putting back is complex, see if you can put in a simple substitute that causes the crash to come back.

Down throught the decades, this has always provided me with an ahah! moment where the bug is exposed. It has always been timeconsuming, but I had found no silver bullet to speed up the process. And I always kicked myself for coding the bug in the first place.

This is not much help, I know, but it's what works for me.

1 members found this post helpful.

thank you wje_lq for the suggestion, i appreciate. I am already trying to piece wise cut the code out to what ever the extent possible. Any suggestion if a memory profiling tool(say mpatrol) can do any help here ?

it seems like the issue is fixed. There i found a pointer allocated some memory but not freed.