This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup.exe SEGV on WinXP/Pro
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 9 Aug 2013 13:54:00 -0400
- Subject: Re: [PATCH] setup.exe SEGV on WinXP/Pro
- References: <877gfw2fqp dot fsf at Rainer dot invalid> <20130809090726 dot GS16868 at calimero dot vinschen dot de> <20130809153313 dot GA2312 at ednor dot casa dot cgf dot cx> <786EBDA1AC46254B813E200779E7AD3602FF22B6 at srv1163ex1 dot flightsafety dot com> <20130809165513 dot GA7420 at ednor dot casa dot cgf dot cx> <20130809174723 dot GA4276 at calimero dot vinschen dot de>
- Reply-to: cygwin-apps at cygwin dot com
On Fri, Aug 09, 2013 at 07:47:23PM +0200, Corinna Vinschen wrote:
>On Aug 9 12:55, Christopher Faylor wrote:
>> On Fri, Aug 09, 2013 at 11:01:32AM -0500, Thrall, Bryan wrote:
>> >Christopher Faylor wrote on 2013-08-09:
>> >> On Fri, Aug 09, 2013 at 11:07:26AM +0200, Corinna Vinschen wrote:
>> >>> On Aug 8 20:34, Achim Gratz wrote:
>> >>>>
>> >>>> I've been having sporadic SEGV on WinXP/Pro just after the MD5 of a
>> >>>> package was checked that used to clear up after a reboot. Today,
>> >with a
>> >>>> freshly built setup.exe this failure was now entirely reproduceable.
>> >>>> I've fixed it by reimplementing the string formatting for the MD5
>> >digest
>> >>>> using C++ stream functions.
>> >>>>
>> >>>
>> >>>>> From 677e2e89d1e4046c967dd1759ac53116f6643bd9 Mon Sep 17
>> >> 00:00:00 2001
>> >>>> From: Achim Gratz <Stromeko@Stromeko.DE>
>> >>>> Date: Thu, 8 Aug 2013 20:23:31 +0200
>> >>>> Subject: [PATCH] fix SEGV on WinXP/Pro
>> >>>>
>> >>>> * csu_util/MD5Sum.cc (MD5Sum::operator std::string() const):
>> >>>> Reimplement using stringstream to avoid a SEGV on WinXP/Pro.
>> >>>
>> >>> Patch applied.
>> >>>
>> >>>> - return std::string(hexdigest);
>> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >>> I'm wondering if that was the problem. This expression constructs a
>> >>> std:string and then immediately destructs it since the scope is
>> >limited
>> >>> to the end of the function (which the return statement is all about).
>> >>> Reading the value of this object in the parent function is basically
>> >>> luck, isn't it?
>> >>
>> >> Sheesh. Yes, that looks like the problem. But doesn't the new code
>> >do
>> >> pretty much the same thing?
>> >>
>> >> + std::ostringstream hexdigest;
>> >> + return hexdigest.str();
>> >
>> >According to this:
>> >
>> >http://stackoverflow.com/questions/275214/scope-and-return-values-in-c
>> >
>> >Returning the object should be ok because it is copied before leaving
>> >the function scope; returning a reference or pointer to the object is
>> >where you get into problems.
>>
>> Thanks for clarifying. Isn't that what the original code did too then?
>
>Not quite. ostringstream::str returns string, the string constructor
>implicitely returns string&. It's sometimes tricky to wrap the brain
>around the differences as far as the scope is concerned.
Perhaps a comment here would help future perusers of this function.
cgf