0

I'm attempting to inspect a process that has "hung" on my server. I am using gdb to attatch to the process like so:

gdb -p PID

Whilst inside gdb I run bt and get the following:

(gdb) bt
#0  0x00007f57f4be73ba in __getpwuid_r (uid=4113672712, resbuf=0x7f57f531ce40, buffer=0x1 <error: Cannot access memory at address 0x1>, buflen=0, 
    result=0x7f57f531a048) at ../nss/getXXbyYY_r.c:198
#1  0x00007f5700000004 in ?? ()
#2  0x0000000000000060 in ?? ()
#3  0x0000000000000001 in ?? ()
#4  0x00007f5700000031 in ?? ()
#5  0x0000000000000000 in ?? ()

Is the Cannot Access Memory Address a potential reason for causing this process to hang? Or does it mean the software has quit but still has a running process?

This is a CasperJS script btw.

BugHunterUK
  • 8,346
  • 16
  • 65
  • 121
  • Sounds like you are attaching to a production version of an application. Those are likely to have optimisations enabled and debugging symbols stripped. So you cannot fully rely on what gdb tells you. For example, with optimisations enabled some of the variable values will not be available to gdb at any given time. So my advice would be to keep the above info as data points. But do not draw firm conclusions on those alone. Unfortunately you'll need to debug further. – kaylum Mar 04 '16 at 21:02

1 Answers1

0

Is the Cannot Access Memory Address a potential reason for causing this process to hang?

No.

It's likely that your entire stack is bogus, and your process is not inside __getpwuid_r at all.

One way this could happen is if you updated system libraries, but have not restarted the process. GDB is then looking at currently installed system libraries, which do not match the copy the process is actually using.

You can prove of disprove this by looking for "(deleted)" entries in /proc/$PID/maps.

If this is indeed the case, you would have to arrange for GDB to see the old versions of system libraries (the ones that were current when the process was started) before you can get a correct stack trace. This answer may help with the setup.

Community
  • 1
  • 1
Employed Russian
  • 199,314
  • 34
  • 295
  • 362