This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: 64bit segfault in cygcheck
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 28 Mar 2013 18:21:27 +0100
- Subject: Re: 64bit segfault in cygcheck
- References: <51545FB9 dot 9070809 at lysator dot liu dot se> <5154626C dot 4020705 at lysator dot liu dot se> <20130328154126 dot GB11845 at calimero dot vinschen dot de> <5154680E dot 9020005 at lysator dot liu dot se>
- Reply-to: cygwin-developers at cygwin dot com
On Mar 28 16:55, Peter Rosin wrote:
> On 2013-03-28 16:41, Corinna Vinschen wrote:
> > On Mar 28 16:31, Peter Rosin wrote:
> >> On 2013-03-28 16:20, Peter Rosin wrote:
> >>> Hi!
> >>>
> >>> I did a "cygcheck -svc", mostly for fun, and got a segfault. A gbd
> >>> session puts the blame on cygcheck.cc:671, which currently has this:
> >>>
> >>> 670: struct tm *tm = localtime ((const time_t *) &(ed->timestamp));
> >>> 671: if (tm->tm_year < 60)
> >>> 672: tm->tm_year += 2000;
> >>>
> >>> The reproducer I have is:
> >>>
> >>> $ cygcheck -v /bin/cygruby191.dll
> >>> Segmentation fault
> >>> $
> >>>
> >>> So, since I'm not set up to build my own cygwin dll (not
> >>> comfortably anyway), I will try a blind patch and leave the
> >>> testing of it to someone else.
> >>>
> >>> I haven't researched what's up with that dll, and why localtime()
> >>> would fail, but checking the return value is the right thing to do
> >>> regardless if there are other issues.
> >>
> >> Sorry for replying to self, but right after hitting send it occurred
> >> to me that it might be type size issue (duh!), and I believe this is
> >> a better patch...
> >>
> >> int is still 32 bits, while time_t is now 64 bits, right?
> >
> > That's right. Thanks a lot for the patch. I'll have a look later today
> > or tomorrow, since I'm currently hunting down my very own SEGV ;)
>
> Meanwhile, after looking at the ExpDirectory definition and seeing
> that the next four bytes are version numbers, I checked the version
> of the ruby dll and it indeed has a version (1.9) embedded while
> most other dlls just has zero. So, it fits. It is in fact the only
> cygwin dll with an embedded version number in my Cygwin 32 install
> that I can find (only looked in /bin though...)
I applied your patch, plus a change to use a more modern date format.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat