From: Michael Enright <mike@kmcardiff.com>
To: cygwin@cygwin.com
Subject: Re: Analyzing a SEG FAULT that gdb doesn't help with
Date: Thu, 30 Jul 2015 18:48:00 -0000 [thread overview]
Message-ID: <CAOC2fq8oRqk7QhgEYjUF1Y-xzh-Df1C=0ON4LzTWoZJXrMxZ_g@mail.gmail.com> (raw)
In-Reply-To: <CAOC2fq-ET7BmUQYOLXV_w_QMZE1rfZ8_JpJvVGF=nDS7gTaWWA@mail.gmail.com>
On Thu, Jul 30, 2015 at 10:46 AM, Michael Enright wrote:
> On Thu, Jul 30, 2015 at 7:39 AM, Jon TURNEY wrote:
>> You need to install the 'cygwin-debuginfo' package for debug symbols for
>> cygwin1.dll
>
> I missed this in my searches. I see now that I should have used the
> "debug" category.
>
>>
>> You also need to point addr2line at those detached debug symbols, as (unlike
>> gdb) it doesn't follow .gnu_debuglink pointers.
>>
>> (I'm assuming you've typoed 6155d363 here and it should be 0x6115D363 as the
>> strace output says)
>
> I've been having trouble getting that number right
>
>>
>> # addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 0x6115D363
>> /usr/src/debug/cygwin-2.1.0-1/newlib/libc/machine/i386/strlen.S:64
>
So I set a breakpoint at that location. After hitting it a couple
dozen times I referred back to the stackdump for some register values.
I replaced the original breakpoint with b *0x6115D363 if $ecx==0
When that hit, I did a backtrace:
(gdb) bt
#0 strlen () at
/usr/src/debug/cygwin-2.1.0-1/newlib/libc/machine/i386/strlen.S:64
#1 0x6115bbc6 in __strftime (s=s@entry=0x28c1c8
"(\274\a\200\300\t`\377\210\340`\377\001", maxsize=maxsize@entry=100,
format=0x6e7e86da <js_Null_str+9683> "Z)",
format@entry=0x6e7e86d8 <js_Null_str+9681> "(%Z)",
tim_p=tim_p@entry=0x28c0ec, era_info=era_info@entry=0x28c078,
alt_digits=alt_digits@entry=0x28c07c)
at /usr/src/debug/cygwin-2.1.0-1/newlib/libc/time/strftime.c:1344
#2 0x6115d1bd in strftime (s=0x28c1c8
"(\274\a\200\300\t`\377\210\340`\377\001", maxsize=100,
format=0x6e7e86d8 <js_Null_str+9681> "(%Z)", tim_p=0x28c0ec)
at /usr/src/debug/cygwin-2.1.0-1/newlib/libc/time/strftime.c:673
#3 0x610e9925 in _sigfe () at sigfe.s:38
#4 0x6e7e86d8 in js_Null_str () from /usr/bin/cygmozjs185-1.0.dll
#5 0x0028c0ec in ?? ()
#6 0x800392ec in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Then ...
(gdb) up
#1 0x6115bbc6 in __strftime (s=s@entry=0x28c1c8
"(\274\a\200\300\t`\377\210\340`\377\001", maxsize=maxsize@entry=100,
format=0x6e7e86da <js_Null_str+9683> "Z)",
format@entry=0x6e7e86d8 <js_Null_str+9681> "(%Z)",
tim_p=tim_p@entry=0x28c0ec, era_info=era_info@entry=0x28c078,
alt_digits=alt_digits@entry=0x28c07c)
at /usr/src/debug/cygwin-2.1.0-1/newlib/libc/time/strftime.c:1344
1344 size = strlen (tznam);
Well, let's just kibitz myself:
(gdb) print tznam
$3 = 0xc07a4000 <error: Cannot access memory at address 0xc07a4000>
(gdb) list
1339 tznam = _tzname[tim_p->tm_isdst > 0];
1340 /* Note that in case of wcsftime this loop only works for
1341 timezone abbreviations using the portable
codeset (aka ASCII).
1342 This seems to be the case, but if that ever
changes, this
1343 loop needs revisiting. */
1344 size = strlen (tznam);
1345 for (i = 0; i < size; i++)
1346 {
1347 if (count < maxsize - 1)
1348 s[count++] = tznam[i];
(gdb) print _tzname
$4 = {0x800cfc48 "\200", <incomplete sequence \356\066>, 0x800cfc44 "PDT"}
(gdb) print _tzname[0]
$5 = 0x800cfc48 "\200", <incomplete sequence \356\066>
(gdb) print _tzname[1]
$6 = 0x800cfc44 "PDT"
So "something happened" when libmozjs tried to convert a time to a
string, and whatever happened has to do with the time zone.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2015-07-30 18:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 23:16 Michael Enright
2015-07-30 14:40 ` Jon TURNEY
2015-07-30 17:46 ` Michael Enright
2015-07-30 18:48 ` Michael Enright [this message]
2015-07-31 12:51 ` Jon TURNEY
2015-07-31 18:46 ` Michael Enright
2015-07-31 20:12 ` Michael Enright
2015-08-01 20:28 ` Brian Inglis
2015-08-02 1:55 ` Michael Enright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOC2fq8oRqk7QhgEYjUF1Y-xzh-Df1C=0ON4LzTWoZJXrMxZ_g@mail.gmail.com' \
--to=mike@kmcardiff.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).