"UpdateStringProc" panic and core dump under AIX and 8.1

0 views
Skip to first unread message

Bill Schongar

unread,
Jul 23, 1999, 3:00:00 AM7/23/99
to
I'm trying to compile Tcl on AIX 4.2 at a client site,
and have run into a problem I haven't seen before,
even on our AIX box here.

What happens is that Tcl compiles fine, but when I
go to run tclsh I get:

"UpdateStringProc should not be invoked for type."

and it dumps core.

What boggles my mind is that this doesn't happen on any
other (non-AIX) platform at the client site, and doesn't happen
here on AIX 4.2 using gcc 2.8.1. The difference is that on their
systems I have to use the IBM C++ set compilers so I can later
link in Tcl with their custom libs.

Does this have something to do with the "fixstrtod" fix? It does
come up during configure and say it finds the Solaris 'buggy'
strtod. I've tried editing that out in the Makefile, just in case, with
no luck.

Compile errors I can wrangle my way through, but this is just
odd to me...

Any help would be greatly appreciated..

-Bill


Paul Duffin

unread,
Jul 26, 1999, 3:00:00 AM7/26/99
to Bill Schongar

What level of Tcl, and what level of compiler ?

Run `dump -H` on the executable and library to see what libraries are
being loaded, are they correct ?

What is the stack trace in the core file ? Run `dbx <tclsh>` and
type "where" ?

The problem you are seeing is probably due to Tcl_GetStringFromObj
being called on a NULL Tcl_Obj pointer.

--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880

Bill Schongar

unread,
Jul 26, 1999, 3:00:00 AM7/26/99
to
Paul Duffin wrote:

>What level of Tcl, and what level of compiler ?


8.1.1, both with and without the Plus Patch.

To be honest, I have no idea which version of the compiler
it is - the man pages on that system were unreliable,
and things like 'cc -V', 'cc -version', etc didn't tell me anything.

>Run `dump -H` on the executable and library to see what libraries are
>being loaded, are they correct ?


--
tclsh:

***Import File Strings***
INDEX PATH BASE MEMBER
0 /home/user/update2000/tcl8.1.1/unix:/usr/local/lib:/usr/lib:/lib
1 libc.a shr.o
2 libbsd.a shr.o
3 libdl.a shr.o
--

It seems so.. the local 4.2 box I have shows the same thing,
with an additional path entry, but the same libs.

>What is the stack trace in the core file ? Run `dbx <tclsh>` and
>type "where" ?

--
(dbx) whereraise(??) at 0xd00800bc
abort() at 0xd001b9a8
Tcl_PanicVA(??, ??) at 0x10015000
Tcl_Panic(0x20002a44, 0x0, 0x0, 0x200, 0x200, 0xfffffff8, 0x20024ef9,
0x2) at 0x100150b0
Tcl_GetString(??) at 0x100127dc
Tcl_ObjGetVar2(??, ??, ??, ??) at 0x1002afbc
TclIncrVar2(??, ??, ??, ??, ??) at 0x10028e8c
TclExecuteByteCode(??, ??) at 0x1001a03c
Tcl_EvalObjEx(??, ??, ??) at 0x10022d2c
TclObjInterpProc(??, ??, ??, ??) at 0x1002d194
EvalObjv(??, ??, ??, ??, ??, ??) at 0x1005b9f8
Tcl_EvalEx(??, ??, ??, ??) at 0x1005d5f4
Tcl_Eval(??, ??) at 0x1005da14
Tcl_Init(??) at 0x1003a158
Tcl_AppInit(??) at 0x10000230
Tcl_Main(??, ??, ??) at 0x100007d4
main(??, ??) at 0x100001e8
--

I get the feeling all those question marks are a bad thing...

>The problem you are seeing is probably due to Tcl_GetStringFromObj
>being called on a NULL Tcl_Obj pointer.


Would this be due to something configured wrong in the Makefile,
such as using fixstrtod when it shouldn't? Or a compiler-specific
change? I'm just not sure what to try...

My big concern is that I only have gcc to test with locally,
and that works fine, but at the remote site they exclusively use
the IBM C++ set compilers. And of course they're locked away
behind a firewall... argh!

I'm just used to my code being what breaks, not the Tcl core. : )

Thanks..

-Bill

Paul Duffin

unread,
Jul 27, 1999, 3:00:00 AM7/27/99
to Bill Schongar
Bill Schongar wrote:
>
> Paul Duffin wrote:
>
> >What level of Tcl, and what level of compiler ?
>
> 8.1.1, both with and without the Plus Patch.
>
> To be honest, I have no idea which version of the compiler
> it is - the man pages on that system were unreliable,
> and things like 'cc -V', 'cc -version', etc didn't tell me anything.
>

Run
lslpp -L \*xlC\*

> >Run `dump -H` on the executable and library to see what libraries are
> >being loaded, are they correct ?
>
> --
> tclsh:
>
> ***Import File Strings***
> INDEX PATH BASE MEMBER
> 0 /home/user/update2000/tcl8.1.1/unix:/usr/local/lib:/usr/lib:/lib
> 1 libc.a shr.o
> 2 libbsd.a shr.o
> 3 libdl.a shr.o
> --
>
> It seems so.. the local 4.2 box I have shows the same thing,
> with an additional path entry, but the same libs.
>

It looks to me as though it is missing the Tcl library.
When I run it against tclsh81 I get

/local/tcl8.1/bin/tclsh8.1:

***Import File Strings***
INDEX PATH BASE MEMBER

0 /local/tcl8.1/lib:/usr/lib:/lib
1 libc.a shr.o
2 libtcl8.1.so

and when I run it against libtcl8.1.so I get

/local/tcl8.1/lib/libtcl8.1.so:

***Import File Strings***
INDEX PATH BASE MEMBER

0 /usr/lib:/lib

1 libc.a shr.o
2 libbsd.a shr.o

> [snipped stack]


>
> Tcl_AppInit(??) at 0x10000230
> Tcl_Main(??, ??, ??) at 0x100007d4
> main(??, ??) at 0x100001e8
> --
>
> I get the feeling all those question marks are a bad thing...
>

The ?? are just markers because Tcl has not been built with symbols.
I would recommend that you rebuild Tcl with both symbols and memory
debugging turned on. To turn symbols on you need to change the Makefile
so it sets CFLAGS to CFLAGS_DEBUG and not CFLAGS_OPTIMISE, to turn
memory debugging on you need to change the Makefile so it sets
MEM_DEBUG_FLAGS to -DTCL_MEM_DEBUG. Once you have done this clean out
the installation and rebuild it.

You may need to rebuild your extension if it uses the ckalloc/... for
its memory allocation. If it uses Tcl_Alloc/... then you don't.

> >The problem you are seeing is probably due to Tcl_GetStringFromObj
> >being called on a NULL Tcl_Obj pointer.
>
> Would this be due to something configured wrong in the Makefile,
> such as using fixstrtod when it shouldn't? Or a compiler-specific
> change? I'm just not sure what to try...
>

It could be an optimisation thing, although I have never run across any
problems with optimisation on AIX, or a real bug.

> My big concern is that I only have gcc to test with locally,
> and that works fine, but at the remote site they exclusively use
> the IBM C++ set compilers. And of course they're locked away
> behind a firewall... argh!
>
> I'm just used to my code being what breaks, not the Tcl core. : )
>

Hope this helps.

Bill Schongar

unread,
Jul 27, 1999, 3:00:00 AM7/27/99
to
Paul Duffin wrote:

>> >Run `dump -H` on the executable and library to see what libraries are
>> >being loaded, are they correct ?

>> It seems so.. the local 4.2 box I have shows the same thing,


>> with an additional path entry, but the same libs.
>It looks to me as though it is missing the Tcl library.


D'oh, sorry, I thought I'd mentioned in the first post that I was
configuring for static libs and tclsh, but looking back I see I foolishly
didn't. I had run into the same thing with a shared build test,
so at this point it seems unrelated, though..

Thanks for all the good pointers! I'm driving down there again today,
so I'll give symbols and memory debugging a shot. I'll also see if
I can borrow a 4.1 or 4.3 system to see if the same behavior
occurs with that compiler.

>It could be an optimisation thing, although I have never run across any
>problems with optimisation on AIX, or a real bug.


Nor have I on our AIX box... it's typically my 'safety' platform
for testing builds. It's always the ones you least expect...

Thanks again,

-Bill

Reply all
Reply to author
Forward
0 new messages