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 <[email protected]> >>>> 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? cgf
