Procfs read error in Solaris 2.9

[ke at alum dot bu dot edu]

Hi

I'm debugging a multithreaded application (32 bits) in sparc Solaris 2.9 (kernel is 64 bits) using GDB 6.8 (32 bits) built from a cross-compiler (built from a Linux box, GCC 4.1.2)

The application is a server process, which spawns a new thread to answer requests it receives. However, after the first request completes successfully, a second request triggers the following message:

"procfs: fetch_registers, get_gregs line 3768, /proc/12591/lwp/4: No such file or directory."

If I run the 64-bit version of GDB, this problem does not appear. However, with the 64 bit GDB I can't access debug information. When it stops at a breakpoint it says it is single stepping until exit from function, which has no line number information. But I can access debug information with the 32 bit version.

I downloaded the weekly snapshot from 7/7 and the same error message appears for the 32 bit version. And now with an added problem, during debug I can't see strings (char arrays). It shows <error reading variable>. And this happens for the simplest of applications (not only multi-threaded).???

I think I've tracked the problem for the fetch_registers error message but I'm not sure how to fix it. I may be way off, but here's what I've found so far.

In the 32-bit version of GDB, in the first reply, procfs_wait is invoked with "why" == PR_FAULTED and "what" == FLTBPT and a retval for the new thread (the thread spawned to answer the request - let's say thread 4) is returned.

When the ecs with thread 4 ptid is passed to handle_inferior_event (inside the wait_for_inferior loop), it triggers a context_switch which changes the inferior_ptid to thread 4. However, this inferior_ptid is never changed back to thread 1 (which spawned thread 4). When thread 4 exits procfs_wait is invoked. It prints an exit message and returns, going next to handle_inferior_event. But now because thread 4's ptid is the same as inferior_ptid, it is not a new thread event. Then after handle_inferior_event, when it goes into resume, when read_pc is called, the call stack eventually tries to read the registers of the inferior_ptid, which is still thread 4 and are thus invalid, triggering the error message above.

The 64-bit version of GDB never seems to generate the PR_FAULTED + FLTBPT combination to procfs_wait.

How should I solve this problem? Also, for the weekly snapshot, any ideas as to why I cannot print string values in GDB (I also think it has to do with procfs - procfs_xfer_memory, or a similar function, but this one I haven't tracked).

Thanks in advance,

Wang Ke
"Andrew"