dl-load.c (ld.so) bug??

dl-load.c (ld.so) bug??

[Troy Benjegerdes]

testcase:

#include <stdio.h>
int main(void){
        char * ptr;
        printf("hello world\n");
        fflush(stdout);
        ptr = (char *)malloc(100);
        free(ptr);
}   


compile this with:
gcc test.c -lefence -g -static

On a PPC glibc-2.1 box, this segfaults in dl-load.c:564

On a x86 Red Hat 6.0 system, it works fine (
[troybenj@mos6 troybenj]$ ./a.out

  Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
hello world
[troybenj@mos6 troybenj]$ 


Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
I suspect it's the former, and if so, this would explain the weird
segfaults I've been seeing.

Can someone that knows glibc better please confirm or deny this for me?

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Hollis R Blanchard]

On Mon, 21 Jun 1999, Troy Benjegerdes wrote:
> 
> testcase:
> 
> #include <stdio.h>
> int main(void){
>         char * ptr;
>         printf("hello world\n");
>         fflush(stdout);
>         ptr = (char *)malloc(100);
>         free(ptr);
> }   
> 
> 
> compile this with:
> gcc test.c -lefence -g -static
> 
> On a PPC glibc-2.1 box, this segfaults in dl-load.c:564
> 
> On a x86 Red Hat 6.0 system, it works fine (
> [troybenj@mos6 troybenj]$ ./a.out
> 
>   Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
> hello world
> [troybenj@mos6 troybenj]$ 
> 
> 
> Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
> I suspect it's the former, and if so, this would explain the weird
> segfaults I've been seeing.
> 
> Can someone that knows glibc better please confirm or deny this for me?

Ok, I don't know squat about glibc, but doesn't the fact that it runs fine
*without* Electric Fence indicate it's a problem with that?

-Hollis


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Troy Benjegerdes]

On Mon, 21 Jun 1999, Hollis R Blanchard wrote:

> On Mon, 21 Jun 1999, Troy Benjegerdes wrote:
> > 
> > testcase:
> > 
> > #include <stdio.h>
> > int main(void){
> >         char * ptr;
> >         printf("hello world\n");
> >         fflush(stdout);
> >         ptr = (char *)malloc(100);
> >         free(ptr);
> > }   
> > 
> > 
> > compile this with:
> > gcc test.c -lefence -g -static
> > 
> > On a PPC glibc-2.1 box, this segfaults in dl-load.c:564
> > 
> > On a x86 Red Hat 6.0 system, it works fine (
> > [troybenj@mos6 troybenj]$ ./a.out
> > 
> >   Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
> > hello world
> > [troybenj@mos6 troybenj]$ 
> > 
> > 
> > Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
> > I suspect it's the former, and if so, this would explain the weird
> > segfaults I've been seeing.
> > 
> > Can someone that knows glibc better please confirm or deny this for me?
> 
> Ok, I don't know squat about glibc, but doesn't the fact that it runs fine
> *without* Electric Fence indicate it's a problem with that?
> 
> -Hollis
> 

No. Electric Fence is designed to catch programming errors, such as
attempting to access memory which was not 'malloc'ed. I have traced this
down extensively a couple of months ago, and found that it does indeed
appear to overrun what it malloced.

In normal operation, if I am correct, the ld.so code is just silently
overwriting some other data. 

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Hollis R Blanchard]

> No. Electric Fence is designed to catch programming errors, such as
> attempting to access memory which was not 'malloc'ed. I have traced this
> down extensively a couple of months ago, and found that it does indeed
> appear to overrun what it malloced.

I have two even simpler test cases for you:

int main(void){
    char *ptr=NULL;
    free(ptr);
}

and

int main(void){
    char *ptr = (char *)malloc(100);
}        

Both of these work fine (or at least *appear* to work fine) without Electric
Fence.

> In normal operation, if I am correct, the ld.so code is just silently
> overwriting some other data. 

If this were the case, wouldn't you expect ridiculous levels of instability?

-Hollis


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Daniel Jacobowitz]

On Mon, Jun 21, 1999 at 10:48:12PM -0400, Hollis R Blanchard wrote:
> 
> > No. Electric Fence is designed to catch programming errors, such as
> > attempting to access memory which was not 'malloc'ed. I have traced this
> > down extensively a couple of months ago, and found that it does indeed
> > appear to overrun what it malloced.
> 
> I have two even simpler test cases for you:
> 
> int main(void){
>     char *ptr=NULL;
>     free(ptr);
> }

Well, that one would probably segfault anyway (or at least, is not
guaranteed not to).

> int main(void){
>     char *ptr = (char *)malloc(100);
> }        

That one's a problem, though :)

> If this were the case, wouldn't you expect ridiculous levels of instability?

Depends entirely on what it overwrote.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Peter Chang]

At 23:09 -0400 06.21.1999, Daniel Jacobowitz wrote:
>On Mon, Jun 21, 1999 at 10:48:12PM -0400, Hollis R Blanchard wrote:
> >
> > > No. Electric Fence is designed to catch programming errors, such as
> > > attempting to access memory which was not 'malloc'ed. I have traced this
> > > down extensively a couple of months ago, and found that it does indeed
> > > appear to overrun what it malloced.
> >
> > I have two even simpler test cases for you:
> >
> > int main(void){
> >     char *ptr=NULL;
> >     free(ptr);
> > }
>
>Well, that one would probably segfault anyway (or at least, is not
>guaranteed not to).

Hmm... the docs taht I have say this:

2 The free function causes the space pointed to by ptr to be 
deallocated, that is, made
available for further allocation. If ptr is a null pointer, no action 
occurs. Otherwise, if
the argument does not match a pointer earlier returned by the calloc, malloc,or
realloc function, or if the space has been deallocated by a call to 
free or realloc,
the behavior is undefined.

> > int main(void){
> >     char *ptr = (char *)malloc(100);
> > }
>
>That one's a problem, though :)

Why? Its allocating memory, but never freeing it. Its a leak, but not 
accessing things out of bounds. I haven't used ElectricFence, but its 
not going to catch a bounds error on this.

> > If this were the case, wouldn't you expect ridiculous levels of 
>instability?
>
>Depends entirely on what it overwrote.

Especially, if the malloc (like most) was sub-allocating from an os 
allocated block. In this case it might be possible that the block 
after the overwritten block was not holding any valid data or at 
least wasn't ever given out by malloc/calloc/realloc.

\p

---
sed quis custodiet ipsos custodes
		--Juvenal *Satire* VI, 165

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Hollis R Blanchard]

On Mon, 21 Jun 1999, Peter Chang wrote:
> 
> At 23:09 -0400 06.21.1999, Daniel Jacobowitz wrote:
> >On Mon, Jun 21, 1999 at 10:48:12PM -0400, Hollis R Blanchard wrote:
> > >
> > > I have two even simpler test cases for you:
> > >
> > > int main(void){
> > >     char *ptr=NULL;
> > >     free(ptr);
> > > }
> >
> >Well, that one would probably segfault anyway (or at least, is not
> >guaranteed not to).
> 
> Hmm... the docs taht I have say this:
> 

[snip]
>  If ptr is a null pointer, no action occurs.
[snip]

Right. In other words, that's legal and should not segfault.

> > > int main(void){
> > >     char *ptr = (char *)malloc(100);
> > > }
> >
> >That one's a problem, though :)
> 
> Why? Its allocating memory, but never freeing it. Its a leak, but not 
> accessing things out of bounds. I haven't used ElectricFence, but its 
> not going to catch a bounds error on this.

Try it. It segfaults. Add a free afterwords if you like. It still segfaults.
Add a printf in front of it, and that printf will never happen. The segfault
starts in __libc_start_main. It makes no sense, but anytime you put a malloc
or a free in a program, EFence makes it segfault (*before* running that malloc
or free).

-Hollis


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Peter Chang]

> > Uhhh... both of these are legal.
>
>Yes, exactly. There is no reason they should do anything bad. Now compile them
>with 'gcc -o bug main.c -lefence -g -static'. They both segfault.

Ooops. I thought that you meant that the were illegal and were not 
getting caught. Sorry.

\p

---
sed quis custodiet ipsos custodes
		--Juvenal *Satire* VI, 165

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Geert Uytterhoeven]

On Wed, 23 Jun 1999, Kevin Puetz wrote:
> Umm... just thought of this - a segfault in __libc_start_main is the symptom
> of an old R4 binary on a glibc2.1 system... did ElectricFence not get
> updated (just a thought)? Then - if both libraries load - it segfaults when
> electricfence initializes _it's_ glibc dynamic link. One could try
> rebuilding the SRPM and see...
> 
> Possible? Or am I on crack (don't know much about efence or glibc internals,
> so... probably the latter.)

I don't think so:

| callisto$ dpkg -s electric-fence
| Package: electric-fence
| Status: install ok installed
| Priority: standard
| Section: devel
| Installed-Size: 48
| Maintainer: Debian QA Group <debian-qa@lists.debian.org>
| Version: 2.1-1
| Depends: libc6 (>= 2.1)
           ^^^^^^^^^^^^^^
| Description: A malloc(3) debugger
|  Use virtual memory hardware to detect illegal memory accesses.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Hollis R Blanchard]

On Wed, 23 Jun 1999, Kevin Puetz wrote:

> Umm... just thought of this - a segfault in __libc_start_main is the symptom
> of an old R4 binary on a glibc2.1 system... did ElectricFence not get
> updated (just a thought)? Then - if both libraries load - it segfaults when
> electricfence initializes _it's_ glibc dynamic link. One could try
> rebuilding the SRPM and see...
> 
> Possible? Or am I on crack (don't know much about efence or glibc internals,
> so... probably the latter.)

Doesn't look like it's an R4 problem... I just rebuilt it and it does the same
thing. A different __libc_start_main thing, I guess.

-Hollis


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Kevin Puetz]

OK, it was just a random thought... before people beat head on wall, it
was something simple to look at. I don't claim enough knowledge to really
make such a statement, anyhow...

> Doesn't look like it's an R4 problem... I just rebuilt it and it does the same
> thing. A different __libc_start_main thing, I guess.
> 
> -Hollis

Kevin Puetz <kp11901@www.cedarnet.org>



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: dl-load.c (ld.so) bug??

[Franz Sirl]

At 00:52 22.06.99 , Troy Benjegerdes wrote:


>testcase:
>
>#include <stdio.h>
>int main(void){
>         char * ptr;
>         printf("hello world\n");
>         fflush(stdout);
>         ptr = (char *)malloc(100);
>         free(ptr);
>}
>
>
>compile this with:
>gcc test.c -lefence -g -static
>
>On a PPC glibc-2.1 box, this segfaults in dl-load.c:564
>
>On a x86 Red Hat 6.0 system, it works fine (
>[troybenj@mos6 troybenj]$ ./a.out
>
>   Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
>hello world
>[troybenj@mos6 troybenj]$
>
>
>Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
>I suspect it's the former, and if so, this would explain the weird
>segfaults I've been seeing.
>
>Can someone that knows glibc better please confirm or deny this for me?

This bug is fixed already in cvs-glibc. I've put up mostly untested RPMS 
for a newer glibc under <ftp://dev.linuxppc.org/users/fsirl/R5>.

It might be that the new IP of dev is still not fully propagated, so use 
169.207.1.122 directly in that case.

Franz.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]