Matias Atria on Thu, 12 Nov 1998 23:09:16 -0500 (EST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

C stack overflow in 2.0.12


Hi,

The following commands cause a segmentation fault in version 2.0.12.alpha:

? a.b=[]
? a.b=concat(a.b, "blah")
? a.b
** CRASH **

I know the input is incorrect (i.e. should be concat(a.b, ["blah"])) but
still, GP shouldn't crash :-)

Anyway, after running gdb in the core file, the backtrace shows

#0  0xdff1c045 in identifier () at ../src/language/anal.c:1106
#1  0xdff1ac51 in truc () at ../src/language/anal.c:701
#2  0xdff1a8f1 in facteur () at ../src/language/anal.c:642
#3  0xdff19fed in expr () at ../src/language/anal.c:410
#4  0xdff1c2d8 in identifier () at ../src/language/anal.c:1175
#5  0xdff1ac51 in truc () at ../src/language/anal.c:701
#6  0xdff1a8f1 in facteur () at ../src/language/anal.c:642
#7  0xdff19fed in expr () at ../src/language/anal.c:410
#8  0xdff19e51 in seq () at ../src/language/anal.c:378
#9  0xdff1975c in lisseq0 (t=0x84a6248 "concat(a.b,\"blah\")", 
    f=0xdff19dc4 <seq>) at ../src/language/anal.c:149
#10 0xdff19809 in lisseq (t=0x84a6248 "concat(a.b,\"blah\")")
    at ../src/language/anal.c:163
#11 0xdff1bf23 in call_fun (p=0x84a6248, args=0x780026c, nparam=1)
    at ../src/language/anal.c:1071
#12 0xdff20b60 in read_member (x=0x8565b00) at ../src/language/anal.c:2735
#13 0xdff1c0be in identifier () at ../src/language/anal.c:1124
#14 0xdff1ac51 in truc () at ../src/language/anal.c:701
#15 0xdff1a8f1 in facteur () at ../src/language/anal.c:642
#16 0xdff19fed in expr () at ../src/language/anal.c:410
#17 0xdff1c2d8 in identifier () at ../src/language/anal.c:1175
#18 0xdff1ac51 in truc () at ../src/language/anal.c:701
#19 0xdff1a8f1 in facteur () at ../src/language/anal.c:642
#20 0xdff19fed in expr () at ../src/language/anal.c:410
#21 0xdff19e51 in seq () at ../src/language/anal.c:378
#22 0xdff1975c in lisseq0 (t=0x84a6248 "concat(a.b,\"blah\")", 
    f=0xdff19dc4 <seq>) at ../src/language/anal.c:149
#23 0xdff19809 in lisseq (t=0x84a6248 "concat(a.b,\"blah\")")
    at ../src/language/anal.c:163
#24 0xdff1bf23 in call_fun (p=0x84a6248, args=0x7800530, nparam=1)
    at ../src/language/anal.c:1071
#25 0xdff20b60 in read_member (x=0x8565ac0) at ../src/language/anal.c:2735

and it keeps going forever (I got bored typing enter to see more lines when
the stack frame count reached 1000), repeating the frames between #12 and
#24 identically (except for the argument to read_member()). 

I'm not familiar enough with PARI internals, so I could not figure out what
is wrong, but I hope this helps to solve the problem.

As I said before, I'm running 2.0.12.alpha, ix86 32-bit version, readline
enabled, under Solaris 2.6 x86.

By the way, now that I'm at it, I would like to suggest a new feature for
GP: In my applications, I have to generate HUGE (>100Mb) data files, pass
the data to another program, and read the ouput back into GP. That works
fine using the extern() command, except that writing the file takes forever.
Would there be a way of speeding this up a bit? I think write() does
fopen(..., "a"), but that is extremely inefficient for very large files,
especially if you have to do thousands of write()'s (as I do). So, there
could be a function that allows one to open a file once and keep it open
(or, better yet, implement the equivalent of popen(cmd, "w")), something
like "open(file, mode)" that returns a descriptor and then be able to do
"write(fd, ...)". I actually experimented with this a bit modifying 2.0.12
what I'm talking about, and it made a big difference, but I don't understand
very well how PARI handles input/output files so I'm sure it can be done a
LOT better, if it's useful to anyone other than myself :-)

Thanks a lot, 

Matias.