Thread: debugging C functions
I'm being dim again so can anyone point me to my mistake please? On a linux system (debian errrr...latest, stable one) and postgresql 7.3.3 Compiling and linking with: cc -g -fpic -I blah -o blah.o blah.c ld -g -fpic -shared -o blah.so blah.o (and trying the link stage with cc instead of ld just on the slim possibility) Then in psql creating the function with: create function blah() returns trigger as '/full/path/blah.so', 'blah' language 'C'; and the trigger with: create trigger blah_trg before insert on blah for each row execute procedure public.blah(); (The function got created in public by postgres but I then switched user before creating the trigger and public isn't in it's search_path) Attaching the debugger to the backend process I can't set a break point on my function, it says 'Function "blah" not defined' and when it segments somewhere under SPI_execp called from my function the stack trace has all the postgres symbols but just a '??' at the place my function is obviously sitting. nm tells me blah is defined in the text segment as an external symbol and without any name mangling. The only thing I can see is that asking nm for all symbols, even the debugging ones, doesn't display anything different to what it shows without that switch. Now I know this looks like it's not a postgresql issue but I'd appreciate any pointers you folks can give. This has me baffled. Thanks -- Nigel Andrews
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > Attaching the debugger to the backend process I can't set a break > point on my function, it says 'Function "blah" not defined' and when > it segments somewhere under SPI_execp called from my function the > stack trace has all the postgres symbols but just a '??' at the place > my function is obviously sitting. You won't be able to set a breakpoint in the function if its shared library hasn't been loaded into the process yet. I'd suggest something like <start fresh session> psql=> LOAD 'libraryname'; <attach to backend with gdb> gdb> b myfunc gdb> cont psql=> SELECT myfunc(); If gdb still claims not to know the function with this approach, you probably also need to issue a "sharedlibrary" command to gdb to force it to absorb symbol definitions from the shlib. I think on most platforms the above sequence will work without that, though. regards, tom lane
Nigel J. Andrews writes: > Attaching the debugger to the backend process I can't set a break point on my > function, it says 'Function "blah" not defined' and when it segments somewhere > under SPI_execp called from my function the stack trace has all the postgres > symbols but just a '??' at the place my function is obviously sitting. Use the command LOAD to load the dynamic object into the server process, then set the break point, then run the function. -- Peter Eisentraut peter_e@gmx.net
On Fri, 20 Jun 2003, Peter Eisentraut wrote: > Nigel J. Andrews writes: > > > Attaching the debugger to the backend process I can't set a break point on my > > function, it says 'Function "blah" not defined' and when it segments somewhere > > under SPI_execp called from my function the stack trace has all the postgres > > symbols but just a '??' at the place my function is obviously sitting. > > Use the command LOAD to load the dynamic object into the server process, > then set the break point, then run the function. Thanks Peter and Tom. I haven't actually checked that a segmentation fault lists my function in the stack trace properly (I fixed that fault by code inspection) however, I had discovered that once the function had run without faulting the symbols were there. There's too many variables to check properly now but I had tried using LOAD before and it made no difference but then I might not have tried the LOAD then attach gdb sequence. The principal mistake I think was my forgetting that the load isn't done until the function is first used. -- Nigel J. Andrews
"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > ... I might not have tried the LOAD then attach gdb sequence. I think you need the "sharedlibrary" command to get gdb to know the symbols in a shlib that was loaded into the process after gdb first attached to it. If you do the LOAD, then attach, you bypass the need to issue a manual "sharedlibrary" command. regards, tom lane