what causes 0x0 in stack frame?

what causes 0x0 in stack frame?

Post by William F. Dowlin » Tue, 11 Jul 2000 04:00:00



Hi all,

I've been having some frustration debugging some swig-generated code
under AIX.  Can anyone help?

This is the situation: I am running a trivial perl program which
dynamically
loads and calls some code in a shared library compiled from C++.  The
compile/link of the library was without error or warning (g++ 2.95.2
comiler, AIX 4.2.1 ld linker).  When perl (5.005.03) tries to execute
the code,
it drops core with the message
        Program received signal SIGILL, Illegal instruction.
and gdb gives a backtrace like
(gdb) bt
#0  0x0 in ?? () from (unknown load module)
#1  0xd3efcd54 in _wrap_print_vector (cv=0x20028148) at
SwigStringTests_wrap.cpp:588
#2  0xd3c34344 in Perl_pp_entersub ()
#3  0xd3c45f80 in Perl_runops_standard ()
#4  0xd3bedb70 in perl_run ()
#5  0x100002b4 in main ()
#6  0x10000178 in __start ()

The address 0x0 at the top of the stack frame must be a clue, but I
don't know what to conclude.  Is this telling me there was in fact a
problem with the link?  (The loadmap looked fine, but I'm fairly
inexperienced at reading that.) How can I further pin down the problem?

Interestingly, the identical code works fine under Solaris.

If you have any idea at all, or suggestions of resources, I'd be very
grateful.

Thanks,

Will

--
William F. Dowling
Institute for Scientific Information
215-386-0100 x-1156

 
 
 

what causes 0x0 in stack frame?

Post by Juli » Tue, 11 Jul 2000 04:00:00




Quote:> Hi all,

> I've been having some frustration debugging some swig-generated code
> under AIX.  Can anyone help?

> This is the situation: I am running a trivial perl program which
> dynamically
> loads and calls some code in a shared library compiled from C++.  The
> compile/link of the library was without error or warning (g++ 2.95.2
> comiler, AIX 4.2.1 ld linker).  When perl (5.005.03) tries to execute
> the code,
> it drops core with the message
> Program received signal SIGILL, Illegal instruction.
> and gdb gives a backtrace like
> (gdb) bt
> #0  0x0 in ?? () from (unknown load module)
> #1  0xd3efcd54 in _wrap_print_vector (cv=0x20028148) at

Prolly either you've jumped through an uninitialized pointer
to address 0x0, or you trashed your return address on the
stack and it wound up being 0x0.

That it works on another platform doesn't mean much -- many
bugs manifest themselves differently from platform to
platform.  Makes debugging all the more fun!

-- Julie.

 
 
 

what causes 0x0 in stack frame?

Post by Jens-Uwe Mag » Wed, 12 Jul 2000 04:00:00



Quote:>This is the situation: I am running a trivial perl program which
>dynamically
>loads and calls some code in a shared library compiled from C++.  The
>compile/link of the library was without error or warning (g++ 2.95.2
>comiler, AIX 4.2.1 ld linker).  When perl (5.005.03) tries to execute
>the code,
>it drops core with the message
>    Program received signal SIGILL, Illegal instruction.
>and gdb gives a backtrace like
>(gdb) bt
>#0  0x0 in ?? () from (unknown load module)
>#1  0xd3efcd54 in _wrap_print_vector (cv=0x20028148) at
>SwigStringTests_wrap.cpp:588
>#2  0xd3c34344 in Perl_pp_entersub ()
>#3  0xd3c45f80 in Perl_runops_standard ()
>#4  0xd3bedb70 in perl_run ()
>#5  0x100002b4 in main ()
>#6  0x10000178 in __start ()

>The address 0x0 at the top of the stack frame must be a clue, but I
>don't know what to conclude.  Is this telling me there was in fact a
>problem with the link?  (The loadmap looked fine, but I'm fairly
>inexperienced at reading that.) How can I further pin down the problem?

You are probably using global or static objects that need constructors
to be run, this includes the standard file streams. These get not
initialized properly in perl5.005. Perl 5.6 supposedly is fixed in this
area (if the current IBM C compiler was used to compile perl) by using
loadAndInit instead of load and terminateAndUnload instead of plain
unload to load and unload shared objects. This does say absolutely
nothing on how this is supposed to work with g++, as I have no idea how
this compiler runs its constructors in shared objects.

--
Jens-Uwe Mager  <pgp-mailto:62CFDB25>

 
 
 

1. Can anyone else confirm this bug (snoop/tcpdump causing IP stack to drop ethernet broadcast frames)

Hi, I've come across some very bizarre behaviour I'm hoping someone
else can confirm.  Seems that while snoop or tcpdump is running --
Solaris's IP stack no longer receives and processes ethernet broadcast
frames.  I've been trying to figure out why arp entries have been
expiring on me for a day or so!

My test server is "5.9 Generic_112233-07 sun4u sparc
SUNW,Sun-Fire-480R"

To re-create:

1. Start up snoop or tcpdump on server 'A', bound to the interface you
want to test.  (snoop -d ce1 host 1.2.3.4 -- for example)
2. On another server 'B', delete the arp entry for 'A' if it exists.
3. On server 'B' attempt to ping server 'A'.

(At this point ping fails/hangs for me because no arp replies are
being received).

4. Stop snoop or tcpdump on server 'A'.
5. Attempt to ping server 'A' again.

Just curious as to whether others can re-create this issue, thanks!

2. Wierd OS error messages

3. gdb: missing frames in frame stack or function name garbled

4. Compiling a small kernel

5. Hardware problems: Mandrake 7.0 tulip: eth0: MMIO Region (0X0@0X0) Unavailable, aborting

6. help on linux !@

7. gcc stack frame layout for linux?

8. mounting Linux drive on AIX

9. Bogus end() stack frames under Linux

10. a RS6000 stack frame

11. Frame Relay stack on Linux

12. request for info on stack and frame pointers on sparc

13. vfork and stack frame