NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-evbmips/47904: Segfault in pthread_getspecific()



>Number:         47904
>Category:       port-evbmips
>Synopsis:       Segfault in pthread_getspecific()
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-evbmips-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 07 13:20:00 +0000 2013
>Originator:     JKB
>Release:        NetBSD 6.1
>Organization:
>Environment:
NetBSD concentrateur-10-0-0-3.localdomain 6.1 NetBSD 6.1 (LOONGSON) evbmips
>Description:
Calling pthread_getspecific() from program causes segmentation fault. I have 
seen these segfaults on miniperl (from make in pkgsrc source tree) and on iftop.

For example :
concentrateur-10-0-0-3# iftop -i te0
interface: te0
Cannot obtain hardware address on this platform
Unable to get IP address for interface: te0
[1]   Segmentation fault (core dumped) iftop -i te0
concentrateur-10-0-0-3# gdb iftop iftop.core 
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips64el--netbsd".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/pkg/sbin/iftop...(no debugging symbols found)...done.
[New process 1]
Core was generated by `iftop'.
Program terminated with signal 11, Segmentation fault.
#0  0x786c6214 in pthread_getspecific () from /usr/lib/libpthread.so.1
(gdb) bt
#0  0x786c6214 in pthread_getspecific () from /usr/lib/libpthread.so.1
#1  0x78625a28 in ?? () from /usr/lib/libc.so.12
warning: GDB can't find the start of the function at 0x78625a26.

    GDB is unable to find the start of the function at 0x78625a26
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x78625a26 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
(gdb) quit

>How-To-Repeat:
To reproduce this bug, only try to execute a program that calls 
pthread_getspecific() function.
>Fix:



Home | Main Index | Thread Index | Old Index