Ah simple, He's got bad memory lol!
Can he document the steps to crash, and can you repeat it, with or without help from valgrind? Cheers, Steve On Thu, 2013-08-29 at 13:57 +1200, Derek Smithies wrote: > Hi, > Thanks for the feedback. > > > ok. - I will be more clear. > > The source code I have, and I can compile it just fine. I then release > it to commercial > customers who use it. One customer has found a method of crashing it. > > Where was the crash - and what caused it? > > Well, I simply cannot give him a debug version of the executable to run. > > As I stated below, it is possible that the debug version will not crash. > > ================= > as you said: > > >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. > > > You may be able to identify clusters of assembly instructions belonging to > >clusters of C code, if the recompilation is not exact. > > which is where I think I will end up. Sigh. I was hoping there was > something I had missed. > > Cheers, > Derek. > > On 29/08/13 13:33, Volker Kuhlmann wrote: > > 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 > > > > -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa _______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
