On Thu 29 Aug 2013 10:52:49 NZST +1200, Derek Smithies wrote: > but the same code compiled without debug fails. Turned out in that > case that the debug code had larger stack sizes > and could cope with very large arrays being placed on the stack.
Memory allocation is system specific I believe, i.e. your program simply accesses an address outside its allocated memory range, and the OS decides how far is too far and whether to allocate more pages or send a SIGSEGV. You get around this by dummy accesses in steps. > The question is: does anyone know of a way of taking a segfault > address (from release version code) and determing the > offending line of C code? Do you have the source code? > Can one generate a map (at compile time) > that relates addresses to lines of code... > You can put > -Wl,-Map=mapfile > into the link command, but this shows how the final executable is > layed out, and does not allow for a correlation to individual lines. This information is exactly what -g puts into the executable. If you didn't compile with -g, you don't have that info available, and the only way to get it is to recompile in a way that results into identical addresses (good luck - compiler, C library, header versions...). > It seems that one should create a map at the time of compile each > source file - but have not seen such an option... One should save a copy compiled with -g. You can get the symbol maps with nm, but only for symbols still in the executable - so if you stripped it to death, you'll only get the symbols required for dynamic linking. nm may be able to produce fake symbols, i.e. some letter with a large number following, but that doesn't help you. I haven't heard of a binary-to-C reverse compiler, at least not open source. > For sure, with optimisation turned on, the assembly instructions > have no direct correlation to lines of code - which makes it a > doubly > hard question.. Indeed. It also makes debugging very difficult (if not pointless) at times, and line numbers tend to be at best approximate. The best you can do is identify the function the segv occurred in, from then you're into a lot of pain involving disassemblers and binary poking. Easier to recompile the source, if you can. You may be able to identify clusters of assembly instructions belonging to clusters of C code, if the recompilation is not exact. If you don't have the source, you're in for one hell of a ride through the bytes and bits, C64 style, except with lot more pain. Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me. _______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
