Home > Archive > C > March 2004 > unable to find Segmentation Fault
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
unable to find Segmentation Fault
|
|
| Till Crueger 2004-03-30, 9:30 am |
| Hi,
I have a nasty segmentation fault in one of my programms. Either it is
hidden fairly well, or i am just too blind to find it.
The relevant part of code looks like this
//reserving memory
screenbuf.data=(color*) malloc(sizeof(color)*screenbuf.size);
[...]
size = screenbuf.size;
[...]
offset=((y+1) * bpl) +(x+1);
if(offset < (size-(bpl+1))){
screenbuf.data[offset].red = config_data.flower_color.left.red;
screenbuf.data[offset].green = config_data.flower_color.left.green;
screenbuf.data[offset].blue = config_data.flower_color.left.blue;
}
When I comment out the three lines in the IF clause, everything works
fine, so this makes me think that the Problem has to be somewhere along
those lines. The code is part of a Visualization plugin for XMMS. In case
you need some more lines of code just let me know and I'll post them.
Thanks
Till
--
Please add "Salt and Peper" to the subject line to bypass my spam filter
| |
| Joona I Palaste 2004-03-30, 9:30 am |
| Till Crueger <TillFC@gmx.net> scribbled the following:
> Hi,
> I have a nasty segmentation fault in one of my programms. Either it is
> hidden fairly well, or i am just too blind to find it.
> The relevant part of code looks like this
>
> //reserving memory
> screenbuf.data=(color*) malloc(sizeof(color)*screenbuf.size);
Well, if you think you need the cast to color* at all, you've probably
not prototyped malloc() correctly, and your program is already broken.
So it might give you a segmentation fault right here.
But assuming malloc() still works correctly...
Are you checking that the allocation succeeds? If it fails,
screenbuf.data will be NULL, and it's no wonder you're getting
segmentation faults.
> [...]
> size = screenbuf.size;
> [...]
>
> offset=((y+1) * bpl) +(x+1);
> if(offset < (size-(bpl+1))){
Assuming bpl is non-negative... if offset < size-bpl-1, then it's
going to be < size as well, and therefore screenbuf.data[offset]
should be in correctly allocated memory.
Of course if either y, bpl or x is negative, you might end up with a
negative offset, in which case it passes the if condition but
screenbuf.data[offset] is outside your allocated memory, causing
segmentation faults when written to.
> screenbuf.data[offset].red = config_data.flower_color.left.red;
> screenbuf.data[offset].green = config_data.flower_color.left.green;
> screenbuf.data[offset].blue = config_data.flower_color.left.blue;
> }
>
>
> When I comment out the three lines in the IF clause, everything works
> fine, so this makes me think that the Problem has to be somewhere along
> those lines. The code is part of a Visualization plugin for XMMS. In case
> you need some more lines of code just let me know and I'll post them.
To give a full answer we would need to know how y, x and bpl are
calculated, and the definition of screenbuf, color and config_data, but
AFAIK the only possibility of segmentation faults can be in negative
values for y, x or bpl, or a failing malloc() call.
--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The truth is out there, man! Way out there!"
- Professor Ashfield
| |
| Serve Laurijssen 2004-03-30, 9:30 am |
|
"Till Crueger" <TillFC@gmx.net> wrote in message
news:c4bt0m$1040$1@f1node01.rhrz.uni-bonn.de...
> offset=((y+1) * bpl) +(x+1);
Your offset is wrong.
You can't get 0, 0 now.
Only get pixels from 0 to width-1 and height-1 instead of 1 to width and
height
> if(offset < (size-(bpl+1))){
> screenbuf.data[offset].red = config_data.flower_color.left.red;
> screenbuf.data[offset].green = config_data.flower_color.left.green;
> screenbuf.data[offset].blue = config_data.flower_color.left.blue;
> }
| |
| Till Crueger 2004-03-30, 9:30 am |
| On Tue, 30 Mar 2004 13:41:35 +0000, Joona I Palaste wrote:
> Are you checking that the allocation succeeds? If it fails,
> screenbuf.data will be NULL, and it's no wonder you're getting
> segmentation faults.
I am doing a simple checking if screenbuf is NULL, so that is no problem.
> Of course if either y, bpl or x is negative, you might end up with a
> negative offset, in which case it passes the if condition but
> screenbuf.data[offset] is outside your allocated memory, causing
> segmentation faults when written to.
I think that is the reason... There is no check wether x or y might be
negative. From the way this data is produced this might actually happen. I
guess I have to restructure the code checking x and y instead of the array
boundaries...
Thanks for your help.
Till
--
Please add "Salt and Peper" to the subject line to bypass my spam filter
| |
| Dan Pop 2004-03-30, 10:30 am |
| In <c4bt0m$1040$1@f1node01.rhrz.uni-bonn.de> "Till Crueger" <TillFC@gmx.net> writes:
>I have a nasty segmentation fault in one of my programms. Either it is
>hidden fairly well, or i am just too blind to find it.
>
>The relevant part of code looks like this
>
> //reserving memory
> screenbuf.data=(color*) malloc(sizeof(color)*screenbuf.size);
>
> [...]
> size = screenbuf.size;
> [...]
>
> offset=((y+1) * bpl) +(x+1);
> if(offset < (size-(bpl+1))){
> screenbuf.data[offset].red = config_data.flower_color.left.red;
> screenbuf.data[offset].green = config_data.flower_color.left.green;
> screenbuf.data[offset].blue = config_data.flower_color.left.blue;
> }
Most likely, offset >= screenbuf.size, but this is not a guessing game:
ask the compiler to insert debugger data, let the program dump core,
then examine the core dump with the debugger. The debugger will tell you
where exactly the segfault happened and let you examine the values of all
your varaibles at that point. In most cases, the bug will be found in
no time at all.
If you're unlucky, your code merely corrupts the malloc arena and the
crash happens in a completely unrelated part of the program. Use a
malloc debugger (e.g. Electric Fence) in this case.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
|
|
|
|
|