Re: [xml] core dump - yes its real and needs a fix.

[stan boehm philips com]

I believe that I have found the source of the problem and await your fix.
Please read on for the details.

While chasing the coredump in libxml, I was able to reduce the problem
to simply coredumping the "example" program provided in the trio-1.2 release.

The following code would cause my system to core dump every time.


int main(void)
{
   ...
  void *p1;
  char *p2;

  trio_printf( "abc\n" );
  trio_printf( "%s\n", "abc" );
  trio_printf( " xxx  %d   \n",  (short)2 );
  trio_printf( " xxx  %d   \n",  2 );
  trio_printf( "%d",  2 );


  trio_printf("%s\n", rcsid);
  ...
}

The problem is that there is not enough stack on my system to support
creating the following buffer in the function TrioWriteNumber().

static void TrioWriteNumber(trio_T *self,
                SLONGEST number, unsigned long flags, int width, int precision,
                int base)
{
  BOOLEAN_T isNegative;

  char buffer[MAX_CHARS_IN(LONGEST)
             * MAX_LOCALE_SEPARATOR_LENGTH
             * MAX_LOCALE_GROUPS];
  ...
}

With the debugger, I arrive at the following sizes:
[ ]trio_printf(const char *format,
               ...)
   {
     int status;
     va_list args;

    char xxx[MAX_CHARS_IN(LONGEST)
               * MAX_LOCALE_SEPARATOR_LENGTH
               * MAX_LOCALE_GROUPS];
[ ]  int a = MAX_LOCALE_SEPARATOR_LENGTH;
[ ]  int b = MAX_LOCALE_GROUPS;
[ ]  int c = MAX_CHARS_IN(LONGEST);
[ ]  int x = sizeof(xxx);

   xxx                    [ array ]
   a                          64
   b                          64
   c                          33
   x                         135168


So we see that "buffer" requires 135168 bytes = 33792 words on QNX.
Looking into it a bit further, we feel that there may be an error
in the way MAX_CHARS_IN(LONGEST) computes its values,
thus leading to the hugh size of 135168 bytes.


trio.c:#define MAX_CHARS_IN(x) (sizeof(x) * CHAR_BIT + 1)


        CHAR_BIT has a value of 8 on our system.


In the equation above, we feel that CHAR_BIT needs a divisor as a function
of the hardware platform/OS.


In the meantime, I would like to know if it is really necessary for
a hard realtime system to support 64 locale groups and if the
MAX_LOCALE_SEPARATOR_LENGTH could not also be reduced.
Perhaps as a function of the OS, more #ifdefs YUK ???

Anyway, I lost a lot of hair on this one.  It was right under my nose
and I could not see it.  Looked everwhere else.
It was a real DOOOOOOOOOOOOH when I finially figured it out.

Looking forward to your solution.  :-)

Stanley J. Boehm 





breese mail1 stofanet dk@SMTP gnome org on 05/24/2001 03:32:13 AM
Sent by:        xml-admin gnome org
To:     xml gnome org@SMTP
cc:      
Subject:        Re: [xml] core dump
Classification: 


stan boehm philips com wrote:

> It is purely related to the trio code.
>
> I suspect, that it is related to how it was compiled on QNX.

I looked through your analysis, and found no obvious symptoms
(and no, trio does not get confused by colons).

I have attached a small example source code, which emulates the
steps in your analysis that are related to trio. Could you please
let me know if it works?

I understand that you feel reluctant to step through the trio code,
but as I don't have access to a QNX machine, the information about
where it loops and the values of the local variables is crucial for
me if I am to fix this problem, so I would appreciate any help I
can get.

Does the compilation of trio emit any compiler warnings? Is 'int'
compiled as signed or unsigned? (some compilers have a setting for
this).

Attachment: qnx.c
Description: Binary data