* [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
2014-12-09 17:22 [Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356 matthew.dahl at yahoo dot com
@ 2014-12-09 17:30 ` matthew.dahl at yahoo dot com
2014-12-09 17:35 ` matthew.dahl at yahoo dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: matthew.dahl at yahoo dot com @ 2014-12-09 17:30 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
2014-12-09 17:22 [Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356 matthew.dahl at yahoo dot com
2014-12-09 17:30 ` [Bug nptl/17691] " matthew.dahl at yahoo dot com
@ 2014-12-09 17:35 ` matthew.dahl at yahoo dot com
2014-12-09 19:26 ` neleai at seznam dot cz
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: matthew.dahl at yahoo dot com @ 2014-12-09 17:35 UTC (permalink / raw)
To: glibc-bugs
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
2014-12-09 17:22 [Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356 matthew.dahl at yahoo dot com
2014-12-09 17:30 ` [Bug nptl/17691] " matthew.dahl at yahoo dot com
2014-12-09 17:35 ` matthew.dahl at yahoo dot com
@ 2014-12-09 19:26 ` neleai at seznam dot cz
2014-12-09 20:45 ` matthew.dahl at yahoo dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: neleai at seznam dot cz @ 2014-12-09 19:26 UTC (permalink / raw)
To: glibc-bugs
[-- 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?id02&actioníit
Change "kr" to "kr."
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
2014-12-09 17:22 [Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356 matthew.dahl at yahoo dot com
` (2 preceding siblings ...)
2014-12-09 19:26 ` neleai at seznam dot cz
@ 2014-12-09 20:45 ` matthew.dahl at yahoo dot com
2014-12-09 21:51 ` neleai at seznam dot cz
2014-12-09 22:02 ` matthew.dahl at yahoo dot com
5 siblings, 0 replies; 7+ messages in thread
From: matthew.dahl at yahoo dot com @ 2014-12-09 20:45 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
2014-12-09 17:22 [Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356 matthew.dahl at yahoo dot com
` (3 preceding siblings ...)
2014-12-09 20:45 ` matthew.dahl at yahoo dot com
@ 2014-12-09 21:51 ` neleai at seznam dot cz
2014-12-09 22:02 ` matthew.dahl at yahoo dot com
5 siblings, 0 replies; 7+ messages in thread
From: neleai at seznam dot cz @ 2014-12-09 21:51 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/17691] Segfault in libpthread-2.7.so at offset 0x356
2014-12-09 17:22 [Bug libc/17691] New: Segfault in libpthread-2.7.so at offset 0x356 matthew.dahl at yahoo dot com
` (4 preceding siblings ...)
2014-12-09 21:51 ` neleai at seznam dot cz
@ 2014-12-09 22:02 ` matthew.dahl at yahoo dot com
5 siblings, 0 replies; 7+ messages in thread
From: matthew.dahl at yahoo dot com @ 2014-12-09 22:02 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread