[Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356

[Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356

[matthew.dahl at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

            Bug ID: 17691
           Summary: Segfault in libpthread-2.7.so at offset 0x356
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: matthew.dahl at yahoo dot com
                CC: drepper.fsp at gmail dot com

I am a software engineer at an avionics company, we have a system in the field
that has on two occasions reported a segmentation fault during startup. Since
this system is in a flight configuration we do not have core dumps enabled nor
is any additional logging available.

The following line is from the syslog.all is all we have to go on currently:

Jan  6 08:15:36 <SYSTEM-NAME> kernel: <APP-NAME>[5220]: segfault at 0 ip
b7576356 sp bfad46f8 error 4 in libpthread-2.7.so[b756a000+15000]


>From our analysis it appears to died at offset 0x356 (b756a000 - bfad46f8) in
libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait
function at instruction (intel asm syntax)

c356:    81 ca 00 00 00 80        or     edx,0x80000000

We have been unable to re-produce this issue here in our lab and I have
exhausted all of my resources attempting to find a root cause.


System Info:
Intel(R) Core(TM)2 CPU L7400
Running Debian Kernel Version 2.6.32.8

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356

[matthew.dahl at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

Matthew Dahl <matthew.dahl at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |nptl

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356

[matthew.dahl at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

--- Comment #1 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
(In reply to Matthew Dahl from comment #0)
> I am a software engineer at an avionics company, we have a system in the
> field that has on two occasions reported a segmentation fault during
> startup. Since this system is in a flight configuration we do not have core
> dumps enabled nor is any additional logging available.
> 
> The following line is from the syslog.all is all we have to go on currently:
> 
> Jan  6 08:15:36 <SYSTEM-NAME> kernel: <APP-NAME>[5220]: segfault at 0 ip
> b7576356 sp bfad46f8 error 4 in libpthread-2.7.so[b756a000+15000]
> 
> 
> From our analysis it appears to died at offset 0x356 (b756a000 - bfad46f8)
> in libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait
> function at instruction (intel asm syntax)
> 
> c356:	81 ca 00 00 00 80    	or     edx,0x80000000
> 
> We have been unable to re-produce this issue here in our lab and I have
> exhausted all of my resources attempting to find a root cause.
> 
> 
> System Info:
> Intel(R) Core(TM)2 CPU L7400
> Running Debian Kernel Version 2.6.32.8

Correction:
>From our analysis it appears to died at offset 0x356 (b7576356 - b756a000) in
libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait
function at instruction (intel asm syntax)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26827-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Dec 09 19:26:08 2014
Return-Path: <glibc-bugs-return-26827-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 25469 invoked by alias); 9 Dec 2014 19:26:07 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 25451 invoked by uid 89); 9 Dec 2014 19:26:06 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.2
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: popelka.ms.mff.cuni.cz
Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Dec 2014 19:26:03 +0000
Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131])	by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id 70947445CB;	Tue,  9 Dec 2014 20:25:58 +0100 (CET)
Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000)	id 2ED675F7E4; Tue,  9 Dec 2014 20:25:58 +0100 (CET)
Date: Tue, 09 Dec 2014 19:26:00 -0000
From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= <neleai@seznam.cz>
To: "matthew.dahl at yahoo dot com" <sourceware-bugzilla@sourceware.org>
Cc: glibc-bugs@sourceware.org
Subject: Re: [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
Message-ID: <20141209192557.GA4641@domone>
References: <bug-17691-131@http.sourceware.org/bugzilla/> <bug-17691-131-Rf6sT9eSnP@http.sourceware.org/bugzilla/>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bug-17691-131-Rf6sT9eSnP@http.sourceware.org/bugzilla/>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-IsSubscribed: yes
X-SW-Source: 2014-12/txt/msg00070.txt.bz2
Content-length: 1709

On Tue, Dec 09, 2014 at 05:35:28PM +0000, matthew.dahl at yahoo dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id\x17691
>
> --- Comment #1 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
> (In reply to Matthew Dahl from comment #0)
> > I am a software engineer at an avionics company, we have a system in the
> > field that has on two occasions reported a segmentation fault during
> > startup. Since this system is in a flight configuration we do not have core
> > dumps enabled nor is any additional logging available.
> >
> > The following line is from the syslog.all is all we have to go on currently:
> >
> > Jan  6 08:15:36 <SYSTEM-NAME> kernel: <APP-NAME>[5220]: segfault at 0 ip
> > b7576356 sp bfad46f8 error 4 in libpthread-2.7.so[b756a000+15000]
> >
> >
> > From our analysis it appears to died at offset 0x356 (b756a000 - bfad46f8)
> > in libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait
> > function at instruction (intel asm syntax)
> >
> > c356:	81 ca 00 00 00 80    	or     edx,0x80000000
> >
> > We have been unable to re-produce this issue here in our lab and I have
> > exhausted all of my resources attempting to find a root cause.
> >

That offset is incorrect, as it does not access memory it cannot cause
segfault.

Most probable cause (unless mutex was corrupted) is that mutex uses tls
to determine tid which was not initialized, which also is previous
instruction in source:

2:      test    %eax, %eax
        jne     4b

        movl    %gs:TID, %edx
        orl     $FUTEX_WAITERS, %edx
        LOCK
        cmpxchgl %edx, (%ebx)
        jnz     4b


I would look if there is robust lock in initializers before main is
called?

[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356

[neleai at seznam dot cz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 7841 bytes --]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

--- Comment #2 from Ondrej Bilka <neleai at seznam dot cz> ---
On Tue, Dec 09, 2014 at 05:35:28PM +0000, matthew.dahl at yahoo dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=17691
> 
> --- Comment #1 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
> (In reply to Matthew Dahl from comment #0)
> > I am a software engineer at an avionics company, we have a system in the
> > field that has on two occasions reported a segmentation fault during
> > startup. Since this system is in a flight configuration we do not have core
> > dumps enabled nor is any additional logging available.
> > 
> > The following line is from the syslog.all is all we have to go on currently:
> > 
> > Jan  6 08:15:36 <SYSTEM-NAME> kernel: <APP-NAME>[5220]: segfault at 0 ip
> > b7576356 sp bfad46f8 error 4 in libpthread-2.7.so[b756a000+15000]
> > 
> > 
> > From our analysis it appears to died at offset 0x356 (b756a000 - bfad46f8)
> > in libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait
> > function at instruction (intel asm syntax)
> > 
> > c356:	81 ca 00 00 00 80    	or     edx,0x80000000
> > 
> > We have been unable to re-produce this issue here in our lab and I have
> > exhausted all of my resources attempting to find a root cause.
> > 

That offset is incorrect, as it does not access memory it cannot cause
segfault.

Most probable cause (unless mutex was corrupted) is that mutex uses tls
to determine tid which was not initialized, which also is previous
instruction in source:

2:      test    %eax, %eax
        jne     4b

        movl    %gs:TID, %edx
        orl     $FUTEX_WAITERS, %edx
        LOCK
        cmpxchgl %edx, (%ebx)
        jnz     4b


I would look if there is robust lock in initializers before main is
called?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26829-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Dec 09 20:19:36 2014
Return-Path: <glibc-bugs-return-26829-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 6674 invoked by alias); 9 Dec 2014 20:19:34 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 6635 invoked by uid 48); 9 Dec 2014 20:19:30 -0000
From: "glibc at chsc dot dk" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug localedata/17692] New: Wrong currency_symbol for da_DK
Date: Tue, 09 Dec 2014 20:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: localedata
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glibc at chsc dot dk
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-17692-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00072.txt.bz2
Content-length: 1743

https://sourceware.org/bugzilla/show_bug.cgi?id=17692

            Bug ID: 17692
           Summary: Wrong currency_symbol for da_DK
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: localedata
          Assignee: unassigned at sourceware dot org
          Reporter: glibc at chsc dot dk
                CC: libc-locales at sourceware dot org

The currency_symbol for da_DK should be changed from "kr" to "kr." (i.e. with a
trailing period).

"kr." is the official spelling[1,2] according to Retskrivningsordbogen[3]
published by the Danish Language Council (Dansk Sprognævn) that is the official
regulatory body of the Danish language.

"kr" is sometimes used informally, but I believe "kr." is much more widespread.
To get an impression, see e.g. [4].


AFAICT "kr" is the preferred spelling in Norway[5] and Sweden[6]. Perhaps this
is how "kr" made its way into da_DK also (it has been unchanged since da_DK was
added to Git/CVS in 1997).


I raised this issue to the contact person for da_DK, Keld Simonsen, in January
2014. He responded that he would look into it, but so far I have not received
any feedback.


[1] http://sproget.dk/lookup?SearchableText=kr
[2]
http://sproget.dk/raad-og-regler/retskrivningsregler/retskrivningsregler/a7-40-60/a7-41-43-punktum/a7-42-forkortelsespunktum/
[3] https://en.wikipedia.org/wiki/Retskrivningsordbogen
[4] https://www.google.dk/search?q=priser+kr+site:dk
[5] http://www.korrekturavdelingen.no/K4Forkortelser.htm
[6] http://www.regeringen.se/content/1/c6/13/15/83/7be35768.pdf#page=55

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26830-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Dec 09 20:20:56 2014
Return-Path: <glibc-bugs-return-26830-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 8279 invoked by alias); 9 Dec 2014 20:20:55 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 8236 invoked by uid 48); 9 Dec 2014 20:20:52 -0000
From: "glibc at chsc dot dk" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug localedata/17692] Wrong currency_symbol for da_DK
Date: Tue, 09 Dec 2014 20:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: localedata
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glibc at chsc dot dk
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-17692-131-l10x1qxaMD@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17692-131@http.sourceware.org/bugzilla/>
References: <bug-17692-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg00073.txt.bz2
Content-length: 317

https://sourceware.org/bugzilla/show_bug.cgi?id\x17692

--- Comment #1 from Christian Schmidt <glibc at chsc dot dk> ---
Created attachment 8002
  --> https://sourceware.org/bugzilla/attachment.cgi?id€02&actioníit
Change "kr" to "kr."

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356

[matthew.dahl at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

--- Comment #3 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
(In reply to Ondrej Bilka from comment #2)
> On Tue, Dec 09, 2014 at 05:35:28PM +0000, matthew.dahl at yahoo dot com
> wrote:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=17691
> > 
> > --- Comment #1 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
> > (In reply to Matthew Dahl from comment #0)
> > > I am a software engineer at an avionics company, we have a system in the
> > > field that has on two occasions reported a segmentation fault during
> > > startup. Since this system is in a flight configuration we do not have core
> > > dumps enabled nor is any additional logging available.
> > > 
> > > The following line is from the syslog.all is all we have to go on currently:
> > > 
> > > Jan  6 08:15:36 <SYSTEM-NAME> kernel: <APP-NAME>[5220]: segfault at 0 ip
> > > b7576356 sp bfad46f8 error 4 in libpthread-2.7.so[b756a000+15000]
> > > 
> > > 
> > > From our analysis it appears to died at offset 0x356 (b756a000 - bfad46f8)
> > > in libpthread-2.7.so, which using objdump is in the __lll_robust_lock_wait
> > > function at instruction (intel asm syntax)
> > > 
> > > c356:	81 ca 00 00 00 80    	or     edx,0x80000000
> > > 
> > > We have been unable to re-produce this issue here in our lab and I have
> > > exhausted all of my resources attempting to find a root cause.
> > > 
> 
> That offset is incorrect, as it does not access memory it cannot cause
> segfault.
> 
> Most probable cause (unless mutex was corrupted) is that mutex uses tls
> to determine tid which was not initialized, which also is previous
> instruction in source:
> 
> 2:      test    %eax, %eax
>         jne     4b
> 
>         movl    %gs:TID, %edx
>         orl     $FUTEX_WAITERS, %edx
>         LOCK
>         cmpxchgl %edx, (%ebx)
>         jnz     4b
> 
> 
> I would look if there is robust lock in initializers before main is
> called?

That is exactly what I was thinking (no memory access, so how a segfault
happened?), any way we have calculated the offset set from our two different
occurrences and both point to the same value (0xC356).
The program is written in C and does nothing too special, main executes, it
creates two pthreads and enters a "running" loop and that is about it, and
99.999....9% of time everything works as expected.

Could you clarify what you mean by your last comment "I would look if there is
robust lock in initializers before main is called?".

Do you mean usage/instances of "pthread_mutex_t mutex =
PTHREAD_MUTEX_INITIALIZER;"? If yes, there are none used.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26833-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Dec 09 21:50:49 2014
Return-Path: <glibc-bugs-return-26833-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 6686 invoked by alias); 9 Dec 2014 21:50:48 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 6671 invoked by uid 89); 9 Dec 2014 21:50:48 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.2
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: popelka.ms.mff.cuni.cz
Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Dec 2014 21:50:46 +0000
Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131])	by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id 994A144765;	Tue,  9 Dec 2014 22:50:41 +0100 (CET)
Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000)	id A3E095F81B; Tue,  9 Dec 2014 22:50:40 +0100 (CET)
Date: Tue, 09 Dec 2014 21:50:00 -0000
From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= <neleai@seznam.cz>
To: "matthew.dahl at yahoo dot com" <sourceware-bugzilla@sourceware.org>
Cc: glibc-bugs@sourceware.org
Subject: Re: [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
Message-ID: <20141209215040.GA3538@domone>
References: <bug-17691-131@http.sourceware.org/bugzilla/> <bug-17691-131-sc26VK7KtN@http.sourceware.org/bugzilla/>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bug-17691-131-sc26VK7KtN@http.sourceware.org/bugzilla/>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-IsSubscribed: yes
X-SW-Source: 2014-12/txt/msg00076.txt.bz2
Content-length: 951

On Tue, Dec 09, 2014 at 08:45:05PM +0000, matthew.dahl at yahoo dot com wrote:
> That is exactly what I was thinking (no memory access, so how a segfault
> happened?), any way we have calculated the offset set from our two different
> occurrences and both point to the same value (0xC356).
> The program is written in C and does nothing too special, main executes, it
> creates two pthreads and enters a "running" loop and that is about it, and
> 99.999....9% of time everything works as expected.
>
> Could you clarify what you mean by your last comment "I would look if there is
> robust lock in initializers before main is called?".
>
> Do you mean usage/instances of "pthread_mutex_t mutex > PTHREAD_MUTEX_INITIALIZER;"? If yes, there are none used.
>
I meant using mutex in C++ constructor or function in __attribute__((constuctor))

If not I do not know how that could happen, only other memory access there
is dereferencing mutex pointer.

[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

--- Comment #4 from Ondrej Bilka <neleai at seznam dot cz> ---
On Tue, Dec 09, 2014 at 08:45:05PM +0000, matthew.dahl at yahoo dot com wrote:
> That is exactly what I was thinking (no memory access, so how a segfault
> happened?), any way we have calculated the offset set from our two different
> occurrences and both point to the same value (0xC356).
> The program is written in C and does nothing too special, main executes, it
> creates two pthreads and enters a "running" loop and that is about it, and
> 99.999....9% of time everything works as expected.
> 
> Could you clarify what you mean by your last comment "I would look if there is
> robust lock in initializers before main is called?".
> 
> Do you mean usage/instances of "pthread_mutex_t mutex =
> PTHREAD_MUTEX_INITIALIZER;"? If yes, there are none used.
>
I meant using mutex in C++ constructor or function in
__attribute__((constuctor))

If not I do not know how that could happen, only other memory access there
is dereferencing mutex pointer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356

[matthew.dahl at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17691

--- Comment #5 from Matthew Dahl <matthew.dahl at yahoo dot com> ---
(In reply to Ondrej Bilka from comment #4)
> On Tue, Dec 09, 2014 at 08:45:05PM +0000, matthew.dahl at yahoo dot com
> wrote:
> > That is exactly what I was thinking (no memory access, so how a segfault
> > happened?), any way we have calculated the offset set from our two different
> > occurrences and both point to the same value (0xC356).
> > The program is written in C and does nothing too special, main executes, it
> > creates two pthreads and enters a "running" loop and that is about it, and
> > 99.999....9% of time everything works as expected.
> > 
> > Could you clarify what you mean by your last comment "I would look if there is
> > robust lock in initializers before main is called?".
> > 
> > Do you mean usage/instances of "pthread_mutex_t mutex =
> > PTHREAD_MUTEX_INITIALIZER;"? If yes, there are none used.
> >
> I meant using mutex in C++ constructor or function in
> __attribute__((constuctor))
> 
> If not I do not know how that could happen, only other memory access there
> is dereferencing mutex pointer.

Ok, well I'm still continuing to attempt to re-produce this issue (not
expecting to see it happen, as I am the 3rd or 4th engineer to look at this;
and we have yet to re-produce it). If I do get any more information I'll post
here, will just consider this a memory corruption issue for now.
Thanks for your time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.