Tom Lane wrote:
> Geoffrey <esoteric@3times25.net> writes:
>> Tom Lane wrote:
>>> Is pcmiler a Postgres-specific backend extension?
>
>> No. It's a standalone application that provides an api to build calls
>> into there product from other applications. What we've done is created
>> functions that are called from the database that use their api.
>
> Did you recompile/relink these glue functions when moving up to the new
> version? Are they built with debugging enabled?
What we are building is built with debugging, but the libraries provided
by pcmiler do not have debugging symbols.
> The trace is *really* suspicious given what you say here. I'm inclined
> to think that what is really happening is that something is jumping to
> never-never land (via a clobbered function pointer or overwriting a
> return address on the stack) and it just happens to end up in FileRead.
> Unfortunately that guess doesn't provide much help for debugging it :-(
I just find it hard to believe that an address is getting clobbered or
some such thing and we just happen to fall into the very beginning of a
function.
I would also have expected that all the parms to the FileRead call would
have been garbage, yet that does not seem to be the case:
#1 0x0814b2e7 in FileRead (file=168481968, buffer=0xbff816ce "", amount=2)
One other note regarding this issue. We have built standalone programs
that execute from the shell to call the same routines from the third
party api and they work.
The point at which the actual failure occurs on the code is the point at
which the process attempts to connect to the pcmiler server process.
--
Until later, Geoffrey
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
