Re: unable to read core generated by valgrind in gdb / aarch64

On 9/4/22 04:16, John Reiser wrote:
>> Any ideas what I might be doing wrong? Or how do I load the core file?
> 
> Why does use of valgrind cause programmers to forget general debugging 
> technique?
> 
> 1. Describe the environment completely.
> The report does not say which compilers and compiler versions were used,
> or if the compiler commands contained any directives about debugging 
> format.
> Such information is necessary to help understand what might be happening
> with regard to debugging and tracebacks.
> 

Yes, I should have included this information - I don't have access to 
the machine at the moment, but I'll share the detailed info early next week.

However, it's running current RasberryPI OS 64-bit version, which is 
based on Debian 11. So it should have the same version of gcc etc.

> 2. Get debugging information whenever invoking a compiler.
> Traceback lines such as "(+0x57a574)[0x682574]" which lack the name
> of a symbol or file, suggest that "-g" debugging info was not requested
> for *all* compilations.  Start over ("make clean; rm -rf '*.[oa]'")
> then re-compile every source file, making be sure to specify "-g"
> and no variant of "-O" or "-On", except possibly "-O0".
> 

This is a bit puzzling. I'm always running valgrind tests with "-O0" and 
possibly with -fno-omit-frame-pointer, as that gives me the most 
reliable results etc. "-g" should be enabled too (thanks to the postgres 
specific --enable-debug configure switch).

> 3. Optimizing for speed comes after achieving correct execution.
> If 'inline' is used anywhere, then re-compile with the compile-time 
> argument
> "-Dinline=/*empty*/" in order to #define 'inline' as a one-word comment.
> If the behavior of the program changes (any difference at all, excepting
> only slower execution), then there is a *design error* in the source code.
> Fix that first.
> 

If I was optimizing for speed, I wouldn't be running with "-O0". I'm not 
sure what's causing the missing symbols, but it certainly is not inline 
functions - we do have a couple of those, but definitely not this high 
in the stack.

The other thing is that when loading the core file into gdb, the 
backtrace is entirely different (and bogus) from what was written into 
the server log (which comes from "backtrace()" - maybe the missing 
symbol names are due to some limitation in this).

> 4. Walk before attempting to run.
> Did you try a simple example?  Write a half-page program with 5 
> subroutines,
> each of which calls the next one, and the last one sends SIGABRT to the 
> process.

I've inspected *thousands* of core files in the last couple years, both 
as part of development and supporting all kinds of systems. And most of 
the time it either works just fine or it's clear why it's not working. 
Except when running under valgrind, in which case I have no idea why it 
doesn't work (with the same compile options and all that).

> Does the .core file when run under valgrind give the correct traceback 
> using gdb?
> 

I'm not sure I understand the questions. In my initial post I showed two 
backtraces - one I extracted from the .core file using gdb, and another 
one that the application itself (postgres) writes into the server log 
(after using backtrace() etc.).

The logged backtrace has a couple missing symbols, but seems reasonable 
otherwise.

The backtrace extracted from the .core file is clearly bogus.


> 5. (Learn and) Use the built-in tools where possible.
> Run the process interactively, invoking valgrind with "--vgdb-error=0",
> and giving the debugger command "(gdb) continue" after establishing
> connectivity between vgdb and the process.
> See the valgrind manual, section 3.2.9 "vgdb command line options".
> When the SIGABRT happens, then vgdb will allow you to use all the ordinary
> gdb commands to get a backtrace, go up and down the stack, examine
> variables and other memory, run
>     (gdb) info proc
>     (gdb) shell cat /proc/$PID/maps
> to see exactly the layout of process memory, etc.
> There are also special commands to access valgrind functionality
> interactively, such as checking for memory leaks.
> 

I already explained why I don't want / can't use the interactive gdb. 
I'm aware of the option, I've used it before, but in this case it's not 
very practical.

regards
Tomas


_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users