Stefan Küng wrote:
> Joseph Galbraith wrote:
>
>>> A stack overflow could do that ... also lack of symbols could be
>>> causing problems with stack unwinding... in other words, what
>>> you see may not be really what you are getting.
>
> Well, at least the stack trace addresses match. They really point to
> where GetFileAttributesEx() is called.
>
>>> Maybe Peter could reproduce this with the shipping binary? If
>>> I recall correctly, you save symbols for those, right? Given that,
>>> you could then debug a dump file.
>
> Yes, I always keep those around for the latest shipped binary.
>
>>> Another possibility would be to compress and upload the symbols
>>> for the nightlies (or even include the symbols in the .msi ?)
>
> my poor ISP would kill me if I would upload that many data every day :)
> Seriously: the nightly uploads are even now about 40MB, with the debug
> symbols, that would easily double.
>
>>> If the stack walk has any relationship to reality, which I tend
>>> to doubt in the absence of symbols, these to frames seem
>>> interesting:
>>>
>>>>> 02003394 00413e27 b0c6c860 01c70ac7 00000000 TSVNCache+0x16c41
>>>>> 020ff108 73100105 02d30788 004593f0 00000002 TSVNCache+0x13e27
>>> It looks like something allocated about a megabyte of stack between
>>> the two frames. Do we use alloca?
>
> Not that I know of. But I guess passing a string to a function would use
> that in the copy constructor. The problem is that we don't have such big
> strings - they would only get that big if they're corrupted.
I don't think that string copy constructors can use alloca
for the string buffer... the memory would "disappear" or be
overwritten as soon as the constructor returned.
The structure of the string of course goes on the stack...
but the buffer for the string is going to come from the
heap. (And a lot of string classes actually use reference
counting tricks to avoid even that buffer during copy
construction.)
Most likely the stack walk screwed up right there and we are
missing a ton of frames... probably the same five or six
frames over and over, since stack overflows in the absence
of alloca are likely recursion.
It sounds like a repo with the official is the best bet...
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Nov 28 18:12:19 2006