[Patch] linuxppc gnuplot segfaults in save

[Patch] linuxppc gnuplot segfaults in save

[Martin Costabel]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

Hi, 

I think I sent this already to the LinuxPPC developers some time ago,
but I had a look into the latest gnuplot-3.7-2.ppc.rpm, and the bug is
still there:

Bug: 
gnuplot-3.7 on LinuxPPC gives a segmentation fault when the command
'save' or 'save set' is used.

Repeat by: 
root[88]#/usr/bin/gnuplot

        G N U P L O T
        Linux version 3.7
        patchlevel 0
        last modified Thu Jan 14 19:34:53 BST 1999
etc.

Terminal type set to 'x11'
gnuplot> save 'foo.gnu'
Segmentation fault

Patch: 
See below. One just has to split an fprintf command into two.
It seems that the fprintf in the LinuxPPC libraries does not support
such long format strings. In gnuplot-3.6, at the corresponding place
there were 10 fprintf commands, one for each line.

In principle, it would be nice if this were included in the gnuplot
sources, but since it seems to be a ppc specific problem, it would be
sufficient to include the patch in the gnuplot-3.7-x.src.rpm for
LinuxPPC (Tom?). 

Or could someone find out what's wrong with the fprintf function in
LinuPPC? Note that this is not specific for one version of glibc. I
tried it on several from glibc-961212 to glibc-2.1.1-3a. Same result.

--
Martin

[-- Attachment #2: gnuplot_save.patch --]
[-- Type: text/plain, Size: 738 bytes --]

--- misc.c.ori	Thu Dec 10 19:33:22 1998
+++ misc.c	Sun Feb  7 00:16:08 1999
@@ -645,17 +645,18 @@
 set pointsize %g\n\
 set encoding %s\n\
 set %spolar\n\
-set %sparametric\n\
+set %sparametric\n",
+	    loff, roff, toff, boff,
+	    pointsize,
+	    encoding_names[encoding],
+	    (polar) ? "" : "no",
+	    (parametric) ? "" : "no");
+    fprintf(fp, "\
 set view %g, %g, %g, %g\n\
 set samples %d, %d\n\
 set isosamples %d, %d\n\
 set %ssurface\n\
 set %scontour",
-	    loff, roff, toff, boff,
-	    pointsize,
-	    encoding_names[encoding],
-	    (polar) ? "" : "no",
-	    (parametric) ? "" : "no",
 	    surface_rot_x, surface_rot_z, surface_scale, surface_zscale,
 	    samples_1, samples_2,
 	    iso_samples_1, iso_samples_2,

Re: [Patch] linuxppc gnuplot segfaults in save

[Tom Rini]

On Thu, 15 Apr 1999, Martin Costabel wrote:

> I think I sent this already to the LinuxPPC developers some time ago,
> but I had a look into the latest gnuplot-3.7-2.ppc.rpm, and the bug is
> still there:

Whoops.  Lost along the line.  Checked into CVS now, and may or may not
make it into the upcoming beta. (might be another full build in time,
might not).

> In principle, it would be nice if this were included in the gnuplot
> sources, but since it seems to be a ppc specific problem, it would be
> sufficient to include the patch in the gnuplot-3.7-x.src.rpm for
> LinuxPPC (Tom?). 

Hmm.  I don't use gnuplot (and thus didn't see the bug and don't have the
source handy), so if any x86/Linux users with glibc 2.1.x installed could
see if they run into the bug..

> Or could someone find out what's wrong with the fprintf function in
> LinuPPC? Note that this is not specific for one version of glibc. I
> tried it on several from glibc-961212 to glibc-2.1.1-3a. Same result.

It failed under the old libs?

---
Tom Rini (TR1265)
http://dobbstown.yeti.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: [Patch] linuxppc gnuplot segfaults in save

[Martin Costabel]

Tom Rini wrote:

> Hmm.  I don't use gnuplot (and thus didn't see the bug and don't have the
> source handy), so if any x86/Linux users with glibc 2.1.x installed could
> see if they run into the bug..

When gnuplot-3.7 came out, this problem was mentioned to one of the
gnuplot discussion groups (which I don't normally read, I use gnuplot
only occasionally, with octave, for example). It didn't get much
attention, because it seems to affect only linuxppc (and who's using
that, anyway?)
 
> > Or could someone find out what's wrong with the fprintf function in
> > LinuPPC? Note that this is not specific for one version of glibc. I
> > tried it on several from glibc-961212 to glibc-2.1.1-3a. Same result.
> 
> It failed under the old libs?

Yes, I compiled gnuplot-3.7 under glibc-961212 (rev 1o, IIRC), and the
result was the same. I managed to track the problem down to the fprintf
call, but I don't know enough C and glibc to go any further.

--
Martin

[[ 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: [Patch] linuxppc gnuplot segfaults in save

[Hans-Bernhard Broeker]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1346 bytes --]

Hello, LinuxPPC people

Let me give a statement, from the view of a gnuplot developper
who hasn't ever used LinuxPPC:

[...]
> Patch: 
> See below. One just has to split an fprintf command into two.
> It seems that the fprintf in the LinuxPPC libraries does not support
> such long format strings. 

I've had a small look at the patch, and the relevant source code.  If my
knowledge of ANSI regulations for the Standard C library doesn't fail me,
the suspected limitation would constitute an outright bug in fprintf(). 
The only length limit for the *printf() functions allowed by ANSI is that
the output generated (not the format string) can be limited to 509 chars
or so. The gnuplot 3.7 source code doesn't hit that wall, I think, so
fprintf() is not allowed to fail this call. 

Martin: have you tried to boil down the suspected fprintf() problem to a
simpler example case (like a small, complete source code using a long
format string that also crashes)?  If not, the real bug could still be
somewhere else, and fprintf might then just trigger the crash, but not be
the real reason for it.

If ElectricFence or Checker-gcc are available for LinuxPPC, it might be a
good idea to use one of those to see where the problem comes from. 

Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: [Patch] linuxppc gnuplot segfaults in save

[Geert Uytterhoeven]

On Thu, 15 Apr 1999, Hans-Bernhard Broeker wrote:
> If ElectricFence or Checker-gcc are available for LinuxPPC, it might be a
> good idea to use one of those to see where the problem comes from. 

| callisto$ dpkg -s electric-fence
| Package: electric-fence
| Status: install ok installed
| Priority: standard
| Section: devel
| Installed-Size: 51
| Maintainer: Siggy Brentrup <bsb@debian.org>
| Version: 2.0.5-4.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: [Patch] linuxppc gnuplot segfaults in save

[Franz Sirl]

At 08:54 15.04.99 , Martin Costabel wrote:
>> > Or could someone find out what's wrong with the fprintf function in
>> > LinuPPC? Note that this is not specific for one version of glibc. I
>> > tried it on several from glibc-961212 to glibc-2.1.1-3a. Same result.
>>
>> It failed under the old libs?
>
>Yes, I compiled gnuplot-3.7 under glibc-961212 (rev 1o, IIRC), and the
>result was the same. I managed to track the problem down to the fprintf
>call, but I don't know enough C and glibc to go any further.

The problem could be egcs, there's a known varargs bug on PPC, which 
happens as soon you have more than 8-10 args. There's a testcase for this 
in the egcs testsuite, gcc.c-torture/execute/980608-1.c, which still fails 
in the development sources. I hope this will be resolved for egcs-1.2 if 
the rewrite of the function epilogue/prologue to use RTL makes it in time...

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.   ]]

Re: [Patch] linuxppc gnuplot segfaults in save

[Lars Hecking]

> The problem could be egcs, there's a known varargs bug on PPC, which 
> happens as soon you have more than 8-10 args. There's a testcase for this 
> in the egcs testsuite, gcc.c-torture/execute/980608-1.c, which still fails 
> in the development sources. I hope this will be resolved for egcs-1.2 if 
> the rewrite of the function epilogue/prologue to use RTL makes it in time...

 Regardless whether this is an egcs problem or not, I'll check the patch
 into the gnuplot source tree. Watch out for gnuplot 3.7.0.6 beta :)


[[ 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: [Patch] linuxppc gnuplot segfaults in save

[Martin Costabel]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

Franz Sirl wrote:
> 
> At 08:54 15.04.99 , Martin Costabel wrote:
> >> > Or could someone find out what's wrong with the fprintf function in
> >> > LinuPPC? Note that this is not specific for one version of glibc. I
> >> > tried it on several from glibc-961212 to glibc-2.1.1-3a. Same result.
> >>
> >> It failed under the old libs?
> >
> >Yes, I compiled gnuplot-3.7 under glibc-961212 (rev 1o, IIRC), and the
> >result was the same. I managed to track the problem down to the fprintf
> >call, but I don't know enough C and glibc to go any further.
> 
> The problem could be egcs, there's a known varargs bug on PPC, which
> happens as soon you have more than 8-10 args. There's a testcase for this
> in the egcs testsuite, gcc.c-torture/execute/980608-1.c, which still fails
> in the development sources. I hope this will be resolved for egcs-1.2 if
> the rewrite of the function epilogue/prologue to use RTL makes it in time...

Here is a minimal example, adapted from the gnuplot sources. If used as
"a.out foo.gnu", it segfaults for me. Compiler is egcs-2.91.66 19990314
(egcs-1.1.2 release) (PowerPC GNU/Linux), glibc-2.1.1-3a. 
gbd backtrace gives

#0  0x171fb0c in strlen () at soinit.c:59
soinit.c:59: No such file or directory.
(gdb) bt
#0  0x171fb0c in strlen () at soinit.c:59
#1  0x1703fe0 in _IO_vfprintf () at vfprintf.c:1554
#2  0x170acf8 in fprintf () at fprintf.c:36
#3  0x18004d4 in test_fprintf (fp=0x18408a8) at gpltst.c:6
#4  0x180053c in main (argc=2, argv=0x7ffff8a4) at gpltst.c:32
#5  0x676e7500 in ?? ()


If I take away the 9th line of output, it runs without segmentation
fault, but the output of the last 2 lines is incorrect. If I take away
the 8th line, too, output of line 7 is still incorrect.

If I keep all 9 lines, but change the first argument 1.1 to 11 and the
first format from %g to %d, there is no bug anymore.

I hope this helps some of the experts to find and fix the bug.

--
Martin

[-- Attachment #2: gpltst.c --]
[-- Type: text/plain, Size: 552 bytes --]

#include <stdio.h>

void test_fprintf(fp)
    FILE *fp;
{
	fprintf(fp, "\
set offsets %g, %g, %g, %g\n\
set pointsize %g\n\
set encoding %s\n\
set %spolar\n\
set %sparametric\n\
set view %g, %g, %g, %g\n\
set samples %d, %d\n\
set isosamples %d, %d\n\
set %ssurface",
	    1.1, 1.2, 1.3, 1.4, 
	    2.1,
	    "3",
	    "4",
	    "5",
	    6.1, 6.2, 6.3, 6.4,
	    71, 72,
	    81, 82,
	    "9"
	    );
	    }

int main(int argc, char** argv)
{
	char* file_name;
	strcpy(file_name, argv[1]);   
	test_fprintf(fopen(file_name, "w"));
	exit(0);
} 

	    

Re: [Patch] linuxppc gnuplot segfaults in save

[Gary Thomas]

On 15-Apr-99 Martin Costabel wrote:
> 
> Tom Rini wrote:
> 
>> Hmm.  I don't use gnuplot (and thus didn't see the bug and don't have the
>> source handy), so if any x86/Linux users with glibc 2.1.x installed could
>> see if they run into the bug..
> 
> When gnuplot-3.7 came out, this problem was mentioned to one of the
> gnuplot discussion groups (which I don't normally read, I use gnuplot
> only occasionally, with octave, for example). It didn't get much
> attention, because it seems to affect only linuxppc (and who's using
> that, anyway?)
>  
>> > Or could someone find out what's wrong with the fprintf function in
>> > LinuPPC? Note that this is not specific for one version of glibc. I
>> > tried it on several from glibc-961212 to glibc-2.1.1-3a. Same result.
>> 
>> It failed under the old libs?
> 
> Yes, I compiled gnuplot-3.7 under glibc-961212 (rev 1o, IIRC), and the
> result was the same. I managed to track the problem down to the fprintf
> call, but I don't know enough C and glibc to go any further.
> 

I'm not familiar with the specifics of the problem being discussed here but
it seems to be a "varargs" problem.  One of the key differences between
Linux/PPC (and indeed PowerPC in general) and virtually every other system
is how "varargs" works.  For most architectures a simple pointer to a 
list of items [typically on the stack] is used.  On the PowerPC, however,
there is an invisible structure which is used to manage the parameters.
Where just copying a pointer works fine on other architectures, these sort
of operations fail on the PowerPC.

This is where I'd look to start with.  (Note: I'm not volunteering :-)

------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------



[[ 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: [Patch] linuxppc gnuplot segfaults in save

[Gabriel Paubert]

On Thu, 15 Apr 1999, Franz Sirl wrote:

> The problem could be egcs, there's a known varargs bug on PPC, which 
> happens as soon you have more than 8-10 args. There's a testcase for this 
> in the egcs testsuite, gcc.c-torture/execute/980608-1.c, which still fails 
> in the development sources. I hope this will be resolved for egcs-1.2 if 
> the rewrite of the function epilogue/prologue to use RTL makes it in time...

Is it related to alignment ? I've already been bitten by the fact that
some alignment constraint has changed between versions of egcs: now
doubles and long long are aligned on a 4 byte boundary when they are
passed in the memory area, earlier versions enforced 8 byte alignment in
these cases AFAIR.

That's the kind of changes I positively hate :-( 

	Gabriel.


[[ 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: [Patch] linuxppc gnuplot segfaults in save

[Franz Sirl]

At 14:28 15.04.99 , Gabriel Paubert wrote:


>On Thu, 15 Apr 1999, Franz Sirl wrote:
>
>> The problem could be egcs, there's a known varargs bug on PPC, which
>> happens as soon you have more than 8-10 args. There's a testcase for this
>> in the egcs testsuite, gcc.c-torture/execute/980608-1.c, which still fails
>> in the development sources. I hope this will be resolved for egcs-1.2 if
>> the rewrite of the function epilogue/prologue to use RTL makes it in time...
>
>Is it related to alignment ? I've already been bitten by the fact that
>some alignment constraint has changed between versions of egcs: now
>doubles and long long are aligned on a 4 byte boundary when they are
>passed in the memory area, earlier versions enforced 8 byte alignment in
>these cases AFAIR.
>
>That's the kind of changes I positively hate :-(

Hmm, there was a change long ago I think. AFAIR it was due to ABI issues, 
but this has probably nothing to do with the bug in question here, which is 
a clear compiler bug. While setting up the function prologue it uses a 
variable which is not yet setup at this time. The net effect is that the 
prologue uses different offsets from the SP than the rest of the function :-(.

BTW, Gabriel, the latest gas snapshots (990413/14) contain a PPC related 
patch from you. Do you consider your patch a bugfix or an extension? I 
currently use the 990403 snapshot for R5 and don't wanna upgrade again 
before R5 release, unless it's a bugfix.

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.   ]]

Re: [Patch] linuxppc gnuplot segfaults in save

[Gabriel Paubert]

On Thu, 15 Apr 1999, Franz Sirl wrote:

> Hmm, there was a change long ago I think. AFAIR it was due to ABI issues, 
> but this has probably nothing to do with the bug in question here, which is 
> a clear compiler bug. While setting up the function prologue it uses a 
> variable which is not yet setup at this time. The net effect is that the 
> prologue uses different offsets from the SP than the rest of the function :-(.

Quite bad :-(

> BTW, Gabriel, the latest gas snapshots (990413/14) contain a PPC related 
> patch from you. Do you consider your patch a bugfix or an extension? I 
> currently use the 990403 snapshot for R5 and don't wanna upgrade again 
> before R5 release, unless it's a bugfix.

IMHO there was a bug and I fixed it: my copy if the SYSV ABI claims that
relocation type R_PPC_SECTOFF (value 33) is 16 bit wide and not 32.  I
needed it for some glue assembly code compiled with -mrelocatable option.
You may consider it as an obscure case: it was considered as 32 bit and
nobody noticed, AFAIK the compiler never generates this kind of relocation
(and when I upgrade to R5 I shall keep my copy of binutils around).

	Gabriel.


[[ 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:[Patch]linuxppc gnuplot segfaults in save

[Dean Luick]

> Here is a minimal example, adapted from the gnuplot sources. If used
as
> "a.out foo.gnu", it segfaults for me. Compiler is egcs-2.91.66
19990314
> (egcs-1.1.2 release) (PowerPC GNU/Linux), glibc-2.1.1-3a.
> gbd backtrace gives

Using egcs 1.0.2 prelease, it looks like egcs is messing up how it
pushes
arguements on the stack.  In partiuclar, egcs should be filling all of
the integer
argument registers, r3-r10.  Instead, it places what should to in r8 in
r10, and placing
what should be in r9 and r10 on the stack.  This leave r8 and r9
completely random, plus
pushes the final two integer arguments (which should be on the stack) 8
bytes off from
their correct position.

Assuming that fprintf correctly interprets the format string, it is no
wonder that
it crashes.

Dean



[[ 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: [Patch]linuxppc gnuplot segfaults in save

[David Edelsohn]

	You can try invoking EGCS with the additional commandline argument
-mdebug-arg for it to print out additional information about how it is
advancing through the arguments of functions and figure out where in
rs6000.c:function_arg() it is not matching what fprintf expects.  FP gets
very complicated.

David

[[ 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: [Patch] linuxppc gnuplot segfaults in save

[Troy Benjegerdes]

There's a problem with the test code posted earlier.. It segfaults on x86
also..

int main(int argc, char** argv)
{
        char* file_name;                    <-----------
        strcpy(file_name, argv[1]);         <----------
        test_fprintf(fopen(file_name, "w"));
        exit(0);
}        

file_name is initially set to 0x0 on the RedHat 5.1 Intel box, thus
causeing a segfault. On PPC, the pointer is initially pointing somewhere
on the stack (in my case to 0x7ffffcf0)

with the following code, it doesn't segfault on the x86 box, and has the
same crash in _IO_vfprintf on my PPC boxes (glibc-2.1 and glibc-1.99)

int main(int argc, char** argv)
{
        test_fprintf(fopen(argv[1], "w"));
        exit(0);
}   

--------------------------------------------------------------------------
| 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.   ]]