* dl-load.c (ld.so) bug??
@ 1999-06-21 22:52 Troy Benjegerdes
1999-06-22 0:04 ` Hollis R Blanchard
0 siblings, 1 reply; 12+ messages in thread
From: Troy Benjegerdes @ 1999-06-21 22:52 UTC (permalink / raw
To: linuxppc-dev
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
1999-06-21 22:52 Troy Benjegerdes
@ 1999-06-22 0:04 ` Hollis R Blanchard
1999-06-22 1:57 ` Troy Benjegerdes
0 siblings, 1 reply; 12+ messages in thread
From: Hollis R Blanchard @ 1999-06-22 0:04 UTC (permalink / raw
To: Troy Benjegerdes; +Cc: linuxppc-dev
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
1999-06-22 0:04 ` Hollis R Blanchard
@ 1999-06-22 1:57 ` Troy Benjegerdes
1999-06-22 2:48 ` Hollis R Blanchard
0 siblings, 1 reply; 12+ messages in thread
From: Troy Benjegerdes @ 1999-06-22 1:57 UTC (permalink / raw
To: Hollis R Blanchard; +Cc: linuxppc-dev
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
1999-06-22 1:57 ` Troy Benjegerdes
@ 1999-06-22 2:48 ` Hollis R Blanchard
1999-06-22 3:09 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Hollis R Blanchard @ 1999-06-22 2:48 UTC (permalink / raw
To: Troy Benjegerdes; +Cc: linuxppc-dev
> 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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
1999-06-22 2:48 ` Hollis R Blanchard
@ 1999-06-22 3:09 ` Daniel Jacobowitz
1999-06-22 4:36 ` Peter Chang
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 1999-06-22 3:09 UTC (permalink / raw
To: linuxppc-dev
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
1999-06-22 3:09 ` Daniel Jacobowitz
@ 1999-06-22 4:36 ` Peter Chang
1999-06-22 13:52 ` Hollis R Blanchard
0 siblings, 1 reply; 12+ messages in thread
From: Peter Chang @ 1999-06-22 4:36 UTC (permalink / raw
To: linuxppc-dev
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
[not found] <Pine.LNX.3.96L.990622003119.5237E-100000@unix47.andrew.cmu.edu>
@ 1999-06-22 4:39 ` Peter Chang
0 siblings, 0 replies; 12+ messages in thread
From: Peter Chang @ 1999-06-22 4:39 UTC (permalink / raw
To: Hollis R Blanchard; +Cc: linuxppc-dev
> > 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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
1999-06-22 4:36 ` Peter Chang
@ 1999-06-22 13:52 ` Hollis R Blanchard
0 siblings, 0 replies; 12+ messages in thread
From: Hollis R Blanchard @ 1999-06-22 13:52 UTC (permalink / raw
To: Peter Chang; +Cc: linuxppc-dev
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
[not found] <199906231258.HAA25989@www.cedarnet.org>
@ 1999-06-23 13:17 ` Geert Uytterhoeven
1999-06-23 14:19 ` Hollis R Blanchard
1 sibling, 0 replies; 12+ messages in thread
From: Geert Uytterhoeven @ 1999-06-23 13:17 UTC (permalink / raw
To: Kevin Puetz; +Cc: Justin Vallon, Hollis R Blanchard, LinuxPPC-Dev List
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
[not found] <199906231258.HAA25989@www.cedarnet.org>
1999-06-23 13:17 ` Geert Uytterhoeven
@ 1999-06-23 14:19 ` Hollis R Blanchard
1999-06-23 14:32 ` Kevin Puetz
1 sibling, 1 reply; 12+ messages in thread
From: Hollis R Blanchard @ 1999-06-23 14:19 UTC (permalink / raw
To: Kevin Puetz; +Cc: Justin Vallon, LinuxPPC-Dev List
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
1999-06-23 14:19 ` Hollis R Blanchard
@ 1999-06-23 14:32 ` Kevin Puetz
0 siblings, 0 replies; 12+ messages in thread
From: Kevin Puetz @ 1999-06-23 14:32 UTC (permalink / raw
To: Hollis R Blanchard; +Cc: Kevin Puetz, Justin Vallon, LinuxPPC-Dev List
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: dl-load.c (ld.so) bug??
[not found] <Pine.LNX.4.04.9906211749280.27642-100000@narn.local.drgw.n et>
@ 1999-06-23 14:37 ` Franz Sirl
0 siblings, 0 replies; 12+ messages in thread
From: Franz Sirl @ 1999-06-23 14:37 UTC (permalink / raw
To: Troy Benjegerdes; +Cc: linuxppc-dev
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. ]]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1999-06-23 14:37 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.3.96L.990622003119.5237E-100000@unix47.andrew.cmu.edu>
1999-06-22 4:39 ` dl-load.c (ld.so) bug?? Peter Chang
[not found] <Pine.LNX.4.04.9906211749280.27642-100000@narn.local.drgw.n et>
1999-06-23 14:37 ` Franz Sirl
[not found] <199906231258.HAA25989@www.cedarnet.org>
1999-06-23 13:17 ` Geert Uytterhoeven
1999-06-23 14:19 ` Hollis R Blanchard
1999-06-23 14:32 ` Kevin Puetz
1999-06-21 22:52 Troy Benjegerdes
1999-06-22 0:04 ` Hollis R Blanchard
1999-06-22 1:57 ` Troy Benjegerdes
1999-06-22 2:48 ` Hollis R Blanchard
1999-06-22 3:09 ` Daniel Jacobowitz
1999-06-22 4:36 ` Peter Chang
1999-06-22 13:52 ` Hollis R Blanchard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.