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

Re: C problem




On Mon, 8 Feb 1999, Idan Sofer wrote:

> gcc -g -lmarzo -o heb heb.c

could it be that you typed '-G' instead of '-g' ? since the '-G' flag
tells the compiler (actually, the linker) to generate a shared library,
not an executable file. if you try to 'execute' that library afterwards,
it might fail in a fasion similar to the one seen in your message.

you also seem to only show us part of the compilation process you've
taken... perhaps more info could supply the required hint.

> GDB is free software and you are welcome to distribute copies of it
> under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" fordetails.
> GDB 4.16 (i586-debian-linux), Copyright 1996 Free Software Foundation,
> Inc...
> (gdb) run
> Starting program: /home/idan/fpc/./heb
> 
> Program received signal SIGSEGV, Segmentation fault.
> _dl_lookup_symbol (undef_name=0x400122ec "Marzo_list_to_string",
>   ref=0xbffffcf0, symbol_scope=0x4000b150,
>   reference_name=0x4000bb08 "/usr/lib/libmarzo.so.0", flags=2)

i hope you didn't develope a habbit of placing 'in-development' libraries
in /usr/lib ?

>   at dl-lookup.c:91
> dl-lookup.c:91: No such file or directory.
> (gdb) bt
> #0  _dl_lookup_symbol (undef_name=0x400122ec "Marzo_list_to_string",
>   ref=0xbffffcf0, symbol_scope=0x4000b150,
>   reference_name=0x4000bb08 "/usr/lib/libmarzo.so.0", flags=2)
>   at dl-lookup.c:91
> #1  0x40005ea1 in fixup (l=0x4000bb30, reloc_offset=1073789744)
>   at ../sysdeps/i386/dl-machine.h:252
> #2  0x40006015 in _dl_runtime_resolve () at dl-runtime.c:138
> #3  0x804856d in main () at heb.c:23
> (gdb)

another possibility: your 'Marzo_Reverse_String' function corrupts memory
in such a way that when the dynamic linker tries to resolve new symbols
its memory image is simply corrupt...

i'd check out all pointer references first. in the 'comercial world' there
are various tools that help you look for memory corrupting code, such as
purify, insure++, etc. now, insure++ has a linux version, and i thin they
have some kind of a free 30-days evaluation period (althought i never
managed to get the license key for the evaluation out of them..).

i'm not sure there is a free-software library that could help you detect
memory corruption (there is dmalloc, but i think it only detects memory
leaks, not corruption, and when i tried it once on a rather large
application, it sloowed it down so much, and used so much memory, and
generated such a large and unreadable log file, that i simply neglected it
and went on chasing memory leaks by hand instead...

guy