FAQ
Hi (EnterpriseDB) folks

I've been working with someone off list to get some information about a
crash they encounter during a batch run. We're generating a crash dump,
but I'm having some issues getting matching symbols so I can examine it.

One thing that would help with this would be if the EnterpriseDB
releases included their build revision in the output of "SELECT
version()", so it's always clear exactly what build is in use.

I've also noticed in this process that the "File version" on
postgres.exe bears no apparent relationship to the EnterpriseDB release
number. For example, postgresql 8.4.2-2 has a File Version of 8.4.2-104
while 8.4.2-1 has a file version of (IIRC) 8.4.2-9343 . Is there any way
that can be improved?

It's always possible to get the user to send their symbols directory, or
to just debug it locally using windbg.exe, but it'd be really nice if it
were easier to reliably match releases to symbol sets.


Even better would be to put zipped symbols directories onto the EDB
download site, arranged by Pg version. Bonus points for having symlinks
from the md5sum of postgres.exe to the matching symbols. Better again
would be to run a public symbol server with symbols for all builds
EnterpriseDB releases:

http://chadaustin.me/2009/03/reporting-crashes-in-imvu-creating-your-very-own-symbol-server/

... so there's no need to play version guessing games, you just point
your debugger at the symbol server and it fetches what it needs on demand.

Come to think of it, I can probably run a public symbol server myself if
the EDB folks don't want to, but it'd be lovely if they were willing to
do so because it could be integrated into the release process to ensure
symbols were never missing for a build that hit public release.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Search Discussions

  • Magnus Hagander at Jun 16, 2011 at 6:47 am

    On Thu, Jun 16, 2011 at 02:52, Craig Ringer wrote:
    Hi (EnterpriseDB) folks

    I've been working with someone off list to get some information about a
    crash they encounter during a batch run. We're generating a crash dump, but
    I'm having some issues getting matching symbols so I can examine it.

    One thing that would help with this would be if the EnterpriseDB releases
    included their build revision in the output of "SELECT version()", so it's
    always clear exactly what build is in use.

    I've also noticed in this process that the "File version" on postgres.exe
    bears no apparent relationship to the EnterpriseDB release number. For
    example, postgresql 8.4.2-2 has a File Version of 8.4.2-104 while 8.4.2-1
    has a file version of (IIRC) 8.4.2-9343 . Is there any way that can be
    improved?
    1) This is not actually an EnterpriseDB thing - those versions and
    stamps are set by the build system
    2) Why -general, and not -hackers? ;) I'll move it...


    To get to your points:

    The last digit of the version number is actually the build *day*. It's
    calculated by the formula:
    my $d = ($year - 100) . "$yday";

    I have a feeling we've overflowed that field. The value today
    should'äve been 11166. I think we overflowed it when the year turned
    2000, without noticing! The docs claim it's a 16 bit integer though,
    which should've worked.

    We could (once we've figured out why it's wrong) put that number in
    the version string as well. Or some other number - if we can pick a
    good one.

    I don't think the EDB installers should have a *different* string than
    what you'd get if you built the same thing manually...

    Even better would be to put zipped symbols directories onto the EDB download
    site, arranged by Pg version. Bonus points for having symlinks from the
    Or right alongside the downloads themselves.
    md5sum of postgres.exe to the matching symbols. Better again would be to run
    a public symbol server with symbols for all builds EnterpriseDB releases:

    http://chadaustin.me/2009/03/reporting-crashes-in-imvu-creating-your-very-own-symbol-server/

    ... so there's no need to play version guessing games, you just point your
    debugger at the symbol server and it fetches what it needs on demand.

    Come to think of it, I can probably run a public symbol server myself if the
    EDB folks don't want to, but it'd be lovely if they were willing to do so
    because it could be integrated into the release process to ensure symbols
    were never missing for a build that hit public release.
    Hmm. That site talks about sharing them over a windows fileshar,e I
    doubt anybody wants to do that publically.

    Now, if this can be made to serve off a simple http (or ftp) server,
    we could probably run a server for it off the infrastructure - but
    that's assuming someone actually uploads the symbols as builds are
    created ;) And it requires the server not to be windows, and using
    simple protocols...

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-general @
categoriespostgresql
postedJun 16, '11 at 12:52a
activeJun 16, '11 at 6:47a
posts2
users2
websitepostgresql.org
irc#postgresql

2 users in discussion

Craig Ringer: 1 post Magnus Hagander: 1 post

People

Translate

site design / logo © 2022 Grokbase