Re: Help understanding x86 assembly debugging with GDB

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Thu, Feb 3, 2011 at 9:13 AM, Peter Watkins <peter_watkins@mentor.com> wrote:

>> 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.

I meant that one can't write:

  char* line.7;

Such names are usually the result of writing:

  int foo() { static char *line; ...}

>> 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

So much for that theory then.

> 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.

If liblsf.so is not thread-safe, this is indeed a problem.


> 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.

A race on this global does sound like a very likely explanation. You
should be able to confirm it using e.g. TSAN
(http://code.google.com/p/data-race-test/wiki/ThreadSanitizer).

It wasn't clear from your message whether libdrmaa.so is available in
source; looks like it is. You may be able to modify it so it locks
around calls into liblsf to avoid the race.

It's also possible that liblsf is intended to be thread-safe, but that
its initialization must be done before multiple threads exist, and it
sounds like you are trying to initialize it from multiple threads at
once.

Cheers,
-- 
Paul Pluzhnikov