[Bug general/4313] New: fcore on 'sleep' process doesn't work on x86_64

[Bug general/4313] New: fcore on 'sleep' process doesn't work on x86_64

[mark at klomp dot org]

As reported at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234879

The following fcore example doesn't work on x86_64:

sleep 1h & pid=$! ;sleep 1;fcore -o /tmp/sleep.core $pid

fcore (from CVS) takes a very long time (about 7 minutes) on the above example
and then generates the following stacktrace:

Exception in thread "main" inua.eio.BufferUnderflowException
   at inua.eio.ByteBuffer.get(fcore)
   at frysk.util.CoredumpAction$CoreMapsBuilder.buildMap(fcore)
   at frysk.sys.proc.MapsBuilder.construct(fcore)
   at frysk.sys.proc.MapsBuilder.construct(fcore)
   at frysk.util.CoredumpAction.write_elf_file(fcore)
   at frysk.util.CoredumpAction.allExistingTasksCompleted(fcore)
   at frysk.proc.ProcBlockAction.checkFinish(fcore)
   at frysk.proc.ProcBlockAction$ProcBlockTaskObserver$1.execute(fcore)
   at frysk.event.EventLoop.runEventLoop(fcore)
   at frysk.event.EventLoop.run(fcore)
   at fcore.main(fcore)


Comment #3 From Phil Muldoon (pmuldoon@redhat.com) 	on 2007-04-03 08:56 EST 
[reply] 	Private

Hi Mark,

Locally (from CVS) I cannot reproduce as I get:

[pmuldoon@localhost filesystems]$ sleep 1h & pid=$! ;sleep 1;fcore -o
/tmp/sleep.core $pid
[1] 8533
[pmuldoon@localhost filesystems]$ 

[pmuldoon@localhost filesystems]$ eu-readelf  -h /tmp/sleep.core.8533 
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Ident Version:                     1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)

Additionally it completes in < 30 seconds. Is there access to your machine so I
can test?


Comment #4 From Mark Wielaard (mwielaard@redhat.com) 	on 2007-04-03 09:11 EST 
[reply] 	Private

(In reply to comment #3)
> Locally (from CVS) I cannot reproduce as I get:
> [...]
> [pmuldoon@localhost filesystems]$ eu-readelf  -h /tmp/sleep.core.8533 
> > [...]
> Additionally it completes in < 30 seconds. Is there access to your machine so I
> can test?

Cool! That looks promising. I am using a x86_64 machine for my tests (looks you
use something 32 bits based). I'll try to find you on irc.gimp.org in #frysk to
coordinate a debugging session.

Thanks,

Mark

-- 
           Summary: fcore on 'sleep' process doesn't work on x86_64
           Product: frysk
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: frysk-bugzilla at sourceware dot org
        ReportedBy: mark at klomp dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=4313

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/4313] fcore on 'sleep' process doesn't work on x86_64

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2007-04-03 15:05 -------
Created an attachment (id=1663)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1663&action=view)
Debug statements patch


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4313

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/4313] fcore on 'sleep' process doesn't work on x86_64

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2007-04-03 15:06 -------
Mark can you apply attachment 1663 as a patch to CVS HEAD and print the output here.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4313

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/4313] fcore on 'sleep' process doesn't work on x86_64

[mark at klomp dot org]

------- Additional Comments From mark at klomp dot org  2007-04-03 15:24 -------
proc.getMainTask().getMemory().get(0x604000, memory, 0, 0x1000);
proc.getMainTask().getMemory().get(0x605000, memory, 0, 0x21000);
proc.getMainTask().getMemory().get(0x3347c19000, memory, 0, 0x1000);
proc.getMainTask().getMemory().get(0x3347c1a000, memory, 0, 0x1000);
proc.getMainTask().getMemory().get(0x3348144000, memory, 0, 0x4000);
proc.getMainTask().getMemory().get(0x3348148000, memory, 0, 0x1000);
proc.getMainTask().getMemory().get(0x3348149000, memory, 0, 0x5000);
proc.getMainTask().getMemory().get(0x2aaaaaaab000, memory, 0, 0x1000);
proc.getMainTask().getMemory().get(0x2aaaaaac8000, memory, 0, 0x2000);
proc.getMainTask().getMemory().get(0x2aaaaaaca000, memory, 0, 0x34ff000);
proc.getMainTask().getMemory().get(0x7fffbd139000, memory, 0, 0x15000);
proc.getMainTask().getMemory().get(0xffffffffff600000, memory, 0, 0x1000);
Exception in thread "main" inua.eio.BufferUnderflowException
   at inua.eio.ByteBuffer.get(fcore)
   at frysk.util.CoredumpAction$CoreMapsBuilder.buildMap(fcore)
   at frysk.sys.proc.MapsBuilder.construct(fcore)
   at frysk.sys.proc.MapsBuilder.construct(fcore)
   at frysk.util.CoredumpAction.write_elf_file(fcore)
   at frysk.util.CoredumpAction.allExistingTasksCompleted(fcore)
   at frysk.proc.ProcBlockAction.checkFinish(fcore)
   at frysk.proc.ProcBlockAction$ProcBlockTaskObserver$1.execute(fcore)
   at frysk.event.PollEventLoop.runEventLoop(fcore)
   at frysk.event.EventLoop.run(fcore)
   at fcore.main(fcore)

According to /proc/<pid>/map this is:
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vdso]

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4313

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/4313] fcore on 'sleep' process doesn't work on x86_64

[pmuldoon at redhat dot com]

------- Additional Comments From pmuldoon at redhat dot com  2007-04-03 16:28 -------
Looking in LinuxPtraceTask fillMemory, the memory is mapped via a PtraceByteBuffer:

      if (getIsa().getWordSize() == 8)
          memory = new PtraceByteBuffer(id.id, PtraceByteBuffer.Area.DATA,
                                        0x7fffffffffffffffl);
      // For 32-bit address space.
      else
          memory = new PtraceByteBuffer(id.id, PtraceByteBuffer.Area.DATA,
                                        0xffffffffl);

Is this bug happening as the maps overflows the mapped space?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4313

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/4313] fcore on 'sleep' process doesn't work on x86_64

[mark at klomp dot org]

------- Additional Comments From mark at klomp dot org  2007-04-04 16:05 -------
Fixed by:

2007-04-04  Tim Moore  <timoore@redhat.com>

        * LinuxPtraceTask.java (fillMemory): Allocate PtraceByteBuffer with
        'unsigned' long (-1) length.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=4313

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug general/4313] fcore on 'sleep' process doesn't work on x86_64

[mark at klomp dot org]

-- 
Bug 4313 depends on bug 3388, which changed state.

Bug 3388 Summary: LinuxTask does not expose full Task memory
http://sourceware.org/bugzilla/show_bug.cgi?id=3388

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |DUPLICATE

http://sourceware.org/bugzilla/show_bug.cgi?id=4313

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.