Re: [Info-Ingres] Stack dump on auditdb - good host vs bad host

Hi Karl,

Now that makes sense! But why it only comes out when I use the -b/-e
flags I'll probably never know!

FYI. No problems on infodb.

However, I've also just come across a new problem which is also specific
to installations on which I've installed OME functions. You'll like this
one...
If I create two procedures in sequence and the first one has a minor
syntactic error, then the second - syntactically correct - procedure
will produce errors like:
E_OP08A2_EXCEPTION Unexpected exception occurred within query
compilation
and a stack dump in the errlog

OR

E_OP0886_QSF_PALLOC Error calling QSF to allocate a piece of memory.
And either:
+ E_QS0001 QSF dynamic memory pool is exhausted.
+ E_QS0018 Request for an illegal piece size. Size must be a positive
number of bytes

Isn't that Cool!

Marty
-----Original Message-----
From: info-ingres-bounces@xxxxxxxxxxxxxxxxxxxxxxxxx
[mailto:info-ingres-bounces@xxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Karl
& Betty Schendel
Sent: 26 September 2007 13:44
To: info-ingres@xxxxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Info-Ingres] Stack dump on auditdb - good host vs bad host

At 11:20 AM +0100 9/26/07, Martin Bowes wrote:
Hi Everyone,

I have two hosts, both running: II 9.0.4 (a64.lnx/105)NPTL + patch
12343
both running: Fedora Core release 5 (Bordeaux)

If I create a brand new database(call it bowtest).
Checkpoint it turning journaling on.
Then execute: auditdb bowtest -b`date +%d-%b-%Y` (ie. Today it will
give: auditdb bowtest -b26-Sep-2007)

One host is perfectly OK with this command.

The other generates the frontend error:
Wed Sep 26 10:53:02 2007 E_DM904A_FATAL_EXCEPTION A fatal error
has occurred in the DMF Facility.

And in the errlog we see a STACK TRACE message:
::[ , ac874200]: Wed Sep 26 10:53:02 2007 Segmentation
Violation (SIGSEGV) @PC 00002aaaaadc5352
RSP 00007fff37b6b120 RBP 00007fff37b6b2a8 RSI 00002aaaac6d70b0
RDI 00000000005341c0 RAX 00000000005de000 RBX 0000000000000000
RCX 0000000000548000 RDX 00007fff00000000

-----------BEGIN STACK TRACE------------
0: 00007fff37b6b2a8 libscf.1.so(sca_add_datatypes+0x312)


That's a bug in dmfinit (single-threaded DMF initialization) that
shows up on a64, it's passing 0 instead of NULL to sca_add_datatypes
(which it is illegally calling directly!). If you fix that, you
discover that NULL is improperly defined on a64_lnx as well.
(as (i4)0 instead of (void *)0, although it turns out that most
of Ingres manages to pick up a correct override definition from
stddef.h.

I sent over a fix for that, but I don't believe it's made it into the
regular code lines yet.

If you don't try to initialize any UDF's or UDT's, I think it
works fine.

Karl

PS I bet you can blow up infodb the same way, that's how I
found it. Any of the standalone DMF programs should barf.
_______________________________________________
Info-Ingres mailing list
Info-Ingres@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.kettleriverconsulting.com/mailman/listinfo/info-ingres

.

Relevant Pages