Daniel Allcock on Mon, 14 Mar 2011 05:40:01 +0100

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

debugging a program that uses libpari

Hi all,

I am debugging a program that uses lipari, and am having trouble debugging because pari seems to hide or demolish the stack trace.  I set a breakpoint in gdb on pari_err, and it does break there when an error arises.  But there is no useful stack information, so I can't figure out which part of my code is causing the problem.

Below is an example of what I have run into.  

I compiled my own code using gcc -O0 to disable things like omitting the stack pointer.

I built the debug version of pari.  (I just redid the install to make sure; I used /Configure -a and chose debugging when offered it.)

I'd appreciate any help about what I am doing wrong.  Am not sure what info might be useful so have just given the overview.  If it matters, I am using the gmp kernel and am programming in C++, using g++.  (Though the library was compiled with gcc.)


~/research/rk3/branch/12/build$ gdb ./classify 
GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Wed Sep 22 02:45:02 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ...... done

(gdb) break pari_err
Breakpoint 1 at 0x4189374bb22421
(gdb) run
Starting program: /Users/allcock/research/rk3/branch/12/build/classify 
Reading symbols for shared libraries +++++. done
could not read candidates from phase1.dat
computing them and saving them there.

Breakpoint 1, 0x00000001003f8421 in pari_err ()
(gdb) bt
#0  0x00000001003f8421 in pari_err ()
#1  0x00000001002d1814 in gtolong ()