On Sun, Dec 19, 2010 at 13:57, Craig Ringer <craig@postnewspapers.com.au> wrote:
> On 19/12/2010 7:51 PM, Magnus Hagander wrote:
>
>>> Great. I pulled the latest from your git tree, tested that, and got much
>>> better results. Crashdump size is back to what I expected. In my test
>>> code,
>>> fcinfo->args and fcinfo->argnull can be examined without problems.
>>> Backtraces look good; see below. It seems to be including backend private
>>> memory again now. Thanks _very_ much for your work on this.
>>
>> Ok, great. I think that leaves us at least complete enough to commit -
>> we can always improve things further as we get some more real world
>> testing.
>>
>>
>>> fcinfo->flinfo is still inaccessible, but I suspect it's in shared
>>> memory,
>>> as it's at 0x00000135 . Ditto fcinfo->resultinfo and fcinfo->context.
>>
>> Hmm. Not sure why those would be in shared memory, that seems strange.
>
> OK, I'll have to do some more digging on that, then. I'm getting on a plane
> in about 2 hours, but will be bringing Visual Studio snapshots, a postgres
> git tree, an XP vm, etc with me, so time permitting I should be able to keep
> on with this.
Ok. I still think what we have now is a great improvement over
nothing. But improvements on top of it is obviously always good :-)
>>> Anyway, here's an example of the backtraces I'm currently getting.
>>> They're
>>> clearly missing some parameters (in shm? Unsure) but provide source
>>> file+line, argument values where resolvable, and the call stack its self.
>>> Locals are accessible at all levels of the stack when you go poking
>>> around
>>> in windbg.
>>
>> Yeah, they're still very useful. Is that a release or debug build?
>
> That's a release build. I'm intentionally testing with release builds
> because I want something that's useful on real-world end-user systems, and
> I'm aware that few Windows users will build Pg for themselves.
Good - I just wanted to be sure that's what you were testing as well.
> (That said, the Perl-based build scripts are some of the least painful build
> tools I've ever worked with on Windows. Only CMake can rival them for
> low-pain Windows compilation.)
:-) Thanks! They're not quite that painless to maintain, but it's not *too* bad.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/