Re: Help understanding x86 assembly debugging with GDB

[Peter Watkins <peter_watkins at mentor dot com>]

Hi Paul,

Thanks for replying.
> But it's not the global "line" that is at address 0x2af5da3cd330; it's
> "line.7" (which, given its illegal name, is probably a function-local
> static variable).
I'm a little confused by the name too. I'm not sure what makes a name 
illegal, but it doesn't look right.

> You can confirm this by 'print&line' (which, I expect, will produce
> something other than 0x2af5da3cd330) and 'info sym 0x2af5da3cd330'.
Here are those two commands:
(gdb) print &line
$1 = (char **) 0x2af5da3cd330

(gdb) info sym 0x2af5da3cd330
line.7 in section .bss of 
/wv/wvlsf/lsf/7.0/linux2.6-glibc2.3-x86_64/lib/liblsf.so

> Also, 'x/gx 0x2af5da3cd330' should (I expect) show 0.
Here's that output:
(gdb) x/gx 0x2af5da3cd330
0x2af5da3cd330 <line.7>:    0x00000000181a3eb0


I found something else that might be the problem. The library I'm using 
(libdrmaa.so) uses threads. libdrmaa.so calls functions in liblsf.so. In 
GDB:
(gdb) info threads
  2 Thread 20019  setConfEnvOv (name=0x2af5da3b9ea0 "LSF_LOG_MASK",
    value=0x2af5da3baea0 "LOG_WARNING", paramList=0x2af5da2e4100, 
overwrite=1)
    at ../lib.initenv.c:2097
* 1 Thread 20020  0x00002af5da1b31b2 in getNextLineD_ (fp=0x181a3c70,
    LineCount=0x40a31e5c, confFormat=1) at ../lib.words.c:785


Partial backtrace for thread 1 (all the data above comes from this thread):
#0  0x00002af5da1b31b2 in getNextLineD_ (fp=0x181a3c70, 
LineCount=0x40a31e5c,
    confFormat=1) at ../lib.words.c:785
#1  0x00002af5da1b35de in getNextLineC_ (fp=0x181a3c70, 
LineCount=0x40a31e5c,
    confFormat=1) at ../lib.words.c:966
#2  0x00002af5da1b3632 in getNextLineC_ (fp=0x181a3c70, 
LineCount=0x40a31e5c,
    confFormat=1) at ../lib.words.c:978
#3  0x00002af5da1b3632 in getNextLineC_ (fp=0x181a3c70, 
LineCount=0x40a31e5c,
    confFormat=1) at ../lib.words.c:978
#4  0x00002af5da192e15 in readfileconfenv (pList1=0x2af5da2e3ce0, 
pList2=0x0,
    confPath=0x40a32100 "/wv/wvlsf/lsf/conf/lsf.conf", filter=0x0)
    at ../lib.initenv.c:1270


Partial backtrace for thread 2:
#0  setConfEnvOv (name=0x2af5da3b9ea0 "LSF_LOG_MASK",
    value=0x2af5da3baea0 "LOG_WARNING", paramList=0x2af5da2e4100, 
overwrite=1)
    at ../lib.initenv.c:2097
#1  0x00002af5da193b99 in setConfEnv (name=0x2af5da3b9ea0 "LSF_LOG_MASK",
    value=0x2af5da3baea0 "LOG_WARNING", paramList=0x2af5da2e3ce0)
    at ../lib.initenv.c:2069
#2  0x00002af5da192ec6 in readfileconfenv (pList1=0x2af5da2e3ce0,
    pList2=0x2af5da6a5020,
    confPath=0x7fff88864ca0 "/wv/wvlsf/lsf/conf/lsf.conf", filter=0x0)
    at ../lib.initenv.c:1288


So as far as I can tell, both thread 1  and thread 2 are reading from 
/wv/wvlsf/lsf/conf/lsf.conf. Thread 1 uses the global variable, "line". 
I'm guessing that thread 2 may also be using this global variable.

My hypothesis:
1) Thread 1 starts to read /wv/wvlsf/lsf/conf/lsf.conf
2) Thread 2 starts to read /wv/wvlsf/lsf/conf/lsf.conf and nulls out "line"
3) Thread 1 reads "line" and moves it into %rax
4) Thread 2 stores a new value into "line"
5) App segfaults when thread 1 tries to access memory at %rax

Do you think this could be the problem? It didn't even occur to me to 
check and see if libdrmaa.so used threads until a little bit ago.


Thanks,

Peter