Panic on new system

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Panic on new system

Rick Hedin
Earlier I inquired about the ctrace facility, that may be too old to still work. 

But my real problem is that my program panics when I run it on a different system. 

It runs fine when I run it on the development system.  But when I move it to the QA system, it panics. 

rcs-dev:/data1/rcs/bin> PANIC: unprotected error in call to Lua API ((null))

PANIC: unprotected error in call to Lua API (attempt to index a string value)

PANIC: unprotected error in call to Lua API (attempt to index a h value)

PANIC: unprotected error in call to Lua API (attempt to index a string value)


Both are Red Hat Enterprise Linux systems.  I built it on the development system, and just brought the executable image over to the QA system. 

How would you go about debugging something like this? 


               Regards, Rick

Reply | Threaded
Open this post in threaded view
|

Re: Panic on new system

Sean Conner
It was thus said that the Great Rick Hedin once stated:

> Earlier I inquired about the ctrace facility, that may be too old to still
> work.
>
> But my real problem is that my program panics when I run it on a different
> system.
>
> It runs fine when I run it on the development system.  But when I move it
> to the QA system, it panics.
>
> rcs-dev:/data1/rcs/bin> PANIC: unprotected error in call to Lua API ((null))
>
> PANIC: unprotected error in call to Lua API (attempt to index a string
> value)
>
> PANIC: unprotected error in call to Lua API (attempt to index a h� value)
>
> PANIC: unprotected error in call to Lua API (attempt to index a string
> value)
>
> Both are Red Hat Enterprise Linux systems.  I built it on the development
> system, and just brought the executable image over to the QA system.
>
> How would you go about debugging something like this?

  I would start with making sure the versions of Lua are the same on both
systems.  And for "same version" 5.1.0 and 5.1.5 would be considered "the
same version" for all intended purposes.

  Also, ctrace only works for Lua versions 4.0 to 5.2, but the module needs
to be compiled with the proper version of Lua (which relates to making sure
what versions of Lua you are using).

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Panic on new system

Rick Hedin
Hi, Sean. 

Both systems report the same version. 

cdx-dev:/home/rhedin/ctrace> lua -v
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio

The ctrace I downloaded was this one. 


Note the 5.1 in the path. 

I wondered whether the version of the operating system could matter.  On the development machine: 

cdx-dev:/home/rhedin/ctrace> cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.10 (Santiago)

On the QA machine, it says it's 6.7.  So they're not the same.  Important? 


                            Regards, Rick

On Fri, May 24, 2019 at 7:24 PM Sean Conner <[hidden email]> wrote:
It was thus said that the Great Rick Hedin once stated:
> Earlier I inquired about the ctrace facility, that may be too old to still
> work.
>
> But my real problem is that my program panics when I run it on a different
> system.
>
> It runs fine when I run it on the development system.  But when I move it
> to the QA system, it panics.
>
> rcs-dev:/data1/rcs/bin> PANIC: unprotected error in call to Lua API ((null))
>
> PANIC: unprotected error in call to Lua API (attempt to index a string
> value)
>
> PANIC: unprotected error in call to Lua API (attempt to index a h� value)
>
> PANIC: unprotected error in call to Lua API (attempt to index a string
> value)
>
> Both are Red Hat Enterprise Linux systems.  I built it on the development
> system, and just brought the executable image over to the QA system.
>
> How would you go about debugging something like this?

  I would start with making sure the versions of Lua are the same on both
systems.  And for "same version" 5.1.0 and 5.1.5 would be considered "the
same version" for all intended purposes.

  Also, ctrace only works for Lua versions 4.0 to 5.2, but the module needs
to be compiled with the proper version of Lua (which relates to making sure
what versions of Lua you are using).

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Panic on new system

Sean Conner
It was thus said that the Great Rick Hedin once stated:

> Hi, Sean.
>
> Both systems report the same version.
>
> cdx-dev:/home/rhedin/ctrace> lua -v
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>
> The ctrace I downloaded was this one.
>
> http://webserver2.tecgraf.puc-rio.br/~lhf/ftp/lua/5.1/ctrace.tar.gz
>
> Note the 5.1 in the path.
>
> I wondered whether the version of the operating system could matter.  On
> the development machine:
>
> cdx-dev:/home/rhedin/ctrace> cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.10 (Santiago)
>
> On the QA machine, it says it's 6.7.  So they're not the same.  Important?

  I'm not sure.  I've always compiled the stuff on the target machine---even
at work we have build servers that match what we have in QA, staging and
production.  One thing to check on each machine would be:

        GenericUnixPrompt% ldd ctrace.so # or whatever the Lua module name is

  An example:

        [spc]lucy:~/projects/lua-conmanorg/lib>ldd syslog.so
        libc.so.6 => /lib/tls/libc.so.6 (0x002e6000)
                /lib/ld-linux.so.2 (0x00b76000)

  But if at all possible, can you compile on the QA machine and test it?  If
it's still a problem, then ... um ... not sure where to go from here.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Panic on new system

Rick Hedin
Hmm.  I'm not sure what I should do with the ldd output.  Make sure it's the same on both systems? 

I'd like to build the program on the target system.  It's not the way we've been doing things at work.  But it seems desirable.  I'll see whether my coworkers will go for it. 

               Regards, Rick


On Fri, May 24, 2019 at 9:26 PM Sean Conner <[hidden email]> wrote:
It was thus said that the Great Rick Hedin once stated:
> Hi, Sean.
>
> Both systems report the same version.
>
> cdx-dev:/home/rhedin/ctrace> lua -v
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>
> The ctrace I downloaded was this one.
>
> http://webserver2.tecgraf.puc-rio.br/~lhf/ftp/lua/5.1/ctrace.tar.gz
>
> Note the 5.1 in the path.
>
> I wondered whether the version of the operating system could matter.  On
> the development machine:
>
> cdx-dev:/home/rhedin/ctrace> cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.10 (Santiago)
>
> On the QA machine, it says it's 6.7.  So they're not the same.  Important?

  I'm not sure.  I've always compiled the stuff on the target machine---even
at work we have build servers that match what we have in QA, staging and
production.  One thing to check on each machine would be:

        GenericUnixPrompt% ldd ctrace.so # or whatever the Lua module name is

  An example:

        [spc]lucy:~/projects/lua-conmanorg/lib>ldd syslog.so
                libc.so.6 => /lib/tls/libc.so.6 (0x002e6000)
                /lib/ld-linux.so.2 (0x00b76000)

  But if at all possible, can you compile on the QA machine and test it?  If
it's still a problem, then ... um ... not sure where to go from here.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Panic on new system

Luiz Henrique de Figueiredo
In reply to this post by Rick Hedin
> PANIC: unprotected error in call to Lua API (attempt to index a h� value)

This is very strange. Clearly 'h�' is not the type of a name in Lua.
It looks like memory corruption. But luaT_typenames is declared as
     const char *const luaT_typenames[];
and so should not be writable, nor should the strings in it.

Reply | Threaded
Open this post in threaded view
|

Re: Panic on new system

Rick Hedin
In reply to this post by Rick Hedin
I should tell the mailing list what caused Lua to panic, so a future person will have a clue. 

Somebody mangled our Makefiles so that a cpp file wasn't recompiled when a header file changed.  It had a different memory map than all the other .o files, so naturally there were problems. 

The problem could have been identified by running the program under Valgrind.  If someone else experiences Lua panics, I recommend they run Valgrind first thing. 

Thanks for your help. 


On Fri, May 24, 2019 at 10:18 PM Rick Hedin <[hidden email]> wrote:
Hmm.  I'm not sure what I should do with the ldd output.  Make sure it's the same on both systems? 

I'd like to build the program on the target system.  It's not the way we've been doing things at work.  But it seems desirable.  I'll see whether my coworkers will go for it. 

               Regards, Rick


On Fri, May 24, 2019 at 9:26 PM Sean Conner <[hidden email]> wrote:
It was thus said that the Great Rick Hedin once stated:
> Hi, Sean.
>
> Both systems report the same version.
>
> cdx-dev:/home/rhedin/ctrace> lua -v
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>
> The ctrace I downloaded was this one.
>
> http://webserver2.tecgraf.puc-rio.br/~lhf/ftp/lua/5.1/ctrace.tar.gz
>
> Note the 5.1 in the path.
>
> I wondered whether the version of the operating system could matter.  On
> the development machine:
>
> cdx-dev:/home/rhedin/ctrace> cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 6.10 (Santiago)
>
> On the QA machine, it says it's 6.7.  So they're not the same.  Important?

  I'm not sure.  I've always compiled the stuff on the target machine---even
at work we have build servers that match what we have in QA, staging and
production.  One thing to check on each machine would be:

        GenericUnixPrompt% ldd ctrace.so # or whatever the Lua module name is

  An example:

        [spc]lucy:~/projects/lua-conmanorg/lib>ldd syslog.so
                libc.so.6 => /lib/tls/libc.so.6 (0x002e6000)
                /lib/ld-linux.so.2 (0x00b76000)

  But if at all possible, can you compile on the QA machine and test it?  If
it's still a problem, then ... um ... not sure where to go from here.

  -spc