public inbox for frysk-bugzilla@sourceware.org
help / color / mirror / Atom feed
* [Bug general/5620] New: RHEL 5.2 occasional backtraces resolve libc as unknown
@ 2008-01-16  8:54 pmuldoon at redhat dot com
  2008-01-16  8:56 ` [Bug general/5620] " pmuldoon at redhat dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: pmuldoon at redhat dot com @ 2008-01-16  8:54 UTC (permalink / raw)
  To: frysk-bugzilla

Running testLinuxCoreFileStackTrace(frysk.proc.dead.TestLinuxCore) ...FAIL
  junit.framework.ComparisonFailure: Compare stack traces
expected:<...__libc_start_main ()...> but was:<...[unknown]...>

This can only be replicated via -r 100 (it normally happens deep into the repeat
run). Occasionally, libc_start_main() ends up being resolved as [unknown]. This
does not happen on f8 as far as I can test. 


Time: 0.126
There was 1 failure:
1)
testLinuxCoreFileStackTrace(frysk.proc.dead.TestLinuxCore)junit.framework.ComparisonFailure:
Compare stack traces expected:<...__libc_start_main ()...> but was:<...[unknown]...>
   at frysk.proc.dead.TestLinuxCore.testLinuxCoreFileStackTrace(funit)
   at frysk.junit.Runner.runCases(funit)
   at frysk.junit.Runner.runTestCases(funit)
   at frysk.pkglibdir.funit.main(funit)

-- 
           Summary: RHEL 5.2 occasional backtraces resolve libc as unknown
           Product: frysk
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: general
        AssignedTo: frysk-bugzilla at sourceware dot org
        ReportedBy: pmuldoon at redhat dot com


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

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug general/5620] RHEL 5.2 occasional backtraces resolve libc as unknown
  2008-01-16  8:54 [Bug general/5620] New: RHEL 5.2 occasional backtraces resolve libc as unknown pmuldoon at redhat dot com
@ 2008-01-16  8:56 ` pmuldoon at redhat dot com
  2008-01-16 21:43 ` pmuldoon at redhat dot com
  2008-01-18  8:14 ` pmuldoon at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: pmuldoon at redhat dot com @ 2008-01-16  8:56 UTC (permalink / raw)
  To: frysk-bugzilla


------- Additional Comments From pmuldoon at redhat dot com  2008-01-16 08:55 -------
This is the output of the corefile that caused the issue. All other frames
resolve fine.

-bash-3.1$ fstack core.26473 
Task #26473
#0 0x08048383 in fourth ()
#1 0x080483ce in third ()
#2 0x0804840d in second ()
#3 0x0804843e in first ()
#4 0x08048477 in main ()
#5 0x00125dec in [unknown]
#6 0x080482c1 in _start ()


-- 


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

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug general/5620] RHEL 5.2 occasional backtraces resolve libc as unknown
  2008-01-16  8:54 [Bug general/5620] New: RHEL 5.2 occasional backtraces resolve libc as unknown pmuldoon at redhat dot com
  2008-01-16  8:56 ` [Bug general/5620] " pmuldoon at redhat dot com
@ 2008-01-16 21:43 ` pmuldoon at redhat dot com
  2008-01-18  8:14 ` pmuldoon at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: pmuldoon at redhat dot com @ 2008-01-16 21:43 UTC (permalink / raw)
  To: frysk-bugzilla


------- Additional Comments From pmuldoon at redhat dot com  2008-01-16 21:42 -------
After analysis I believe this is the issue:

Occasionally the vdso gets relocated to a location that libc occupies. This
causes the libc libraries to be relocated, and causing the [unknown] library in
the backtrace.  This really designates an unrelocated libc bug. Or in fact, any
solib relocation bug.

In the linkmap table there is a l_addr field which designates absolute location
of a map in memory. In practice this should equal to the l_addr + virt start
address of the LOAD statement of the solib in question. This relocation is not
being taken into account in corefile modeling. It seems a rare occasion. At best
it seems it only occurs when the vdso is located where an solib should live, and
the solib is shifted.

-- 


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

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug general/5620] RHEL 5.2 occasional backtraces resolve libc as unknown
  2008-01-16  8:54 [Bug general/5620] New: RHEL 5.2 occasional backtraces resolve libc as unknown pmuldoon at redhat dot com
  2008-01-16  8:56 ` [Bug general/5620] " pmuldoon at redhat dot com
  2008-01-16 21:43 ` pmuldoon at redhat dot com
@ 2008-01-18  8:14 ` pmuldoon at redhat dot com
  2 siblings, 0 replies; 4+ messages in thread
From: pmuldoon at redhat dot com @ 2008-01-18  8:14 UTC (permalink / raw)
  To: frysk-bugzilla



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|frysk-bugzilla at sourceware|pmuldoon at redhat dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-01-18  8:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-16  8:54 [Bug general/5620] New: RHEL 5.2 occasional backtraces resolve libc as unknown pmuldoon at redhat dot com
2008-01-16  8:56 ` [Bug general/5620] " pmuldoon at redhat dot com
2008-01-16 21:43 ` pmuldoon at redhat dot com
2008-01-18  8:14 ` pmuldoon at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).