SIGSEGV in memcpy() when starting a n application

[Sting]

Hello,
I am getting SIGSEGV immedaitely in the initialization of my app.
by GDB I see that it happens in memcpy() when starting a n application

These also happens when restarting the OS (I use Linux redhat 8) .

Does anybody know what can cause it ?
the 2 pointers which are arguments to memcpy seems to be valid.

regards,
sting

[Barry Margolin]

In article <2ff4a208.0307250645.4e8958be@posting.google.com >,
Sting <zstingx@hotmail.com> wrote:

>Hello,
>I am getting SIGSEGV immedaitely in the initialization of my app.
>by GDB I see that it happens in memcpy() when starting a n application

>These also happens when restarting the OS (I use Linux redhat 8) .

You mean that while the system is booting, the kernel logs a message about
a segmentation violation? Sounds to me like something has been corrupted.

>Does anybody know what can cause it ?
>the 2 pointers which are arguments to memcpy seems to be valid.

Can you post a simple test case that shows it?

--
Barry Margolin, [email]barry.margolin@level3.com[/email]
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[Kurtis D. Rader]

On Fri, 25 Jul 2003 07:45:18 +0000, Sting wrote:

> I am getting SIGSEGV immedaitely in the initialization of my app. by GDB
> I see that it happens in memcpy() when starting a n application
>
> These also happens when restarting the OS (I use Linux redhat 8) .
>
> Does anybody know what can cause it ? the 2 pointers which are arguments
> to memcpy seems to be valid.

Presumably you have also verified that the length is valid. That is,
all bytes in the ranges [src, src+n) and [dest, dst+n) are valid?

It is possible, but implausible, that this is an OS (e.g., glibc) or
kernel problem. I'll give you 100 to 1 odds the fault lies with the
application. Either the source and/or destination address is invalid
or the entire range of addresses extending from those starting points
to the final byte defined by the length argument are not valid.

As Mr. Margolin pointed out without a small example that illustrates
the problem you are unlikely to get a useful answer to the question
you posed.

[Sting]

Thnxs,
I do not mean that while the system is booting, the kernel logs a message about
a segmentation violation . This does not happen
in boot time ; boot passes OK. It happens while running my application.

I made some attempts to make it happen again , but now it
fails with a SIGSEGV in malloc ;It seems to me again that
these problems are connected , so down below is the code for malloc
(because it seems to me that this problem is even more severe
because I do not see a reason why malloc() with 200k should fail ; I have
enough free memory (more than 20MB free mem) .

the malloc method is :

int size = 202752;
if (v4lDisplayFrame == NULL)
{
v4lDisplayFrame = (char*)malloc(size);
printf("v4lDisplayFrame is null\n");
}

where v4lDisplayFrame is declared as :
static char* v4lDisplayFrame;

and defined in the *.cpp file like this:"
char* V4lGrabber::v4lDisplayFrame;

(this initilaizes it to null)

and the gdb stack backtracing gives :

0 0x40417f52 in _int_malloc () from /lib/libc.so.6
#1 0x40417484 in malloc () from /lib/libc.so.6
#2 0x08053d85 in V4lGrabber::setDisplayFrameAfterSave(unsigned char*) (
this=0x8182f48, frame=0x408c4168 '\200' <repeats 200 times>...)
at video/grabber-video4linux.cpp:462
#3 0x08053fce in V4lGrabber::grab() (this=0x8182f48)
at video/grabber-video4linux.cpp:734
#4 0x0804b05e in transmitThread (arg=0x0) at win32/win32.cpp:658
#5 0x40283c0e in pthread_start_thread_event () from /lib/libpthre

I am using a redhat 8.0 with the follwing glibc rpm:
glibc-2.3.2-4.80.6


and the kernel version is 2.4.18-27.8.0

I appreciate your effort to help.
regards,
sting




"Kurtis D. Rader" <krader@skepticism.us> wrote in message news:<pan.2003.07.25.19.03.42.851861@skepticism.us >...

> On Fri, 25 Jul 2003 07:45:18 +0000, Sting wrote:
>

> > I am getting SIGSEGV immedaitely in the initialization of my app. by GDB
> > I see that it happens in memcpy() when starting a n application
> >
> > These also happens when restarting the OS (I use Linux redhat 8) .
> >
> > Does anybody know what can cause it ? the 2 pointers which are arguments
> > to memcpy seems to be valid.

>
> Presumably you have also verified that the length is valid. That is,
> all bytes in the ranges [src, src+n) and [dest, dst+n) are valid?
>
> It is possible, but implausible, that this is an OS (e.g., glibc) or
> kernel problem. I'll give you 100 to 1 odds the fault lies with the
> application. Either the source and/or destination address is invalid
> or the entire range of addresses extending from those starting points
> to the final byte defined by the length argument are not valid.
>
> As Mr. Margolin pointed out without a small example that illustrates
> the problem you are unlikely to get a useful answer to the question
> you posed.