[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: segfault in 'svn up' on trunk

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 22 Jan 2009 16:37:42 +0100

They should NOT be switched over without prejudice. Total -1 to that.

Review them? Sure. But I'm very much against a simple search/replace.
That's bogus.

Cheers,
-g

On Thu, Jan 22, 2009 at 16:19, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> C. Michael Pilato wrote:
>>
>> Stefan Sperling wrote:
>>>
>>> On Wed, Jan 21, 2009 at 11:11:59PM +0100, Bert Huijben wrote:
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stefan Sperling [mailto:stsp_at_elego.de]
>>>>> Sent: Wednesday, January 21, 2009 11:06 PM
>>>>> To: Greg Stein
>>>>> Cc: Hyrum K. Wright; dev_at_subversion.tigris.org
>>>>> Subject: Re: segfault in 'svn up' on trunk
>>>>>
>>>>> On Wed, Jan 21, 2009 at 04:02:54PM +0100, Greg Stein wrote:
>>>>>>
>>>>>> 0x69737265 looks like ascii characters: i s r e
>>>>>>
>>>>>> Somehow the path pointer is getting munged by some text?
>>>>>
>>>>> We need to audit that code more.
>>>>
>>>> Note that this was just a dangling pointer in a svn_wc_notify_t
>>>> structure
>>>> that wasn't initialized with apr_pcalloc as I expected, but with
>>>> apr_palloc.
>>>> See r35366.
>>>
>>> Thanks!
>>>
>>> Maybe we should also do an apr_palloc -> apr_pcalloc sweep?
>>
>> +1. I know, I know, I know that careful coders shouldn't need to force a
>> memset(0) on all their allocations. But sometimes we just aren't
>> perfectly
>> careful coders, and the cost of such runtime crutches approaches zero
>> daily
>> (and has already, in my opinion, dipped well below the threshold of
>> user-visibility).
>
> FWIW, there are 403 locations of apr_palloc() in our code which will need to
> be switched over.
>
> -Hyrum
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1043258
Received on 2009-01-22 16:37:58 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.