Crashing dlopen() on Sharp Zaurus C860

From: Dr. Nikolaus Schaller (hns_at_computer.org)
Date: 12/07/04 

Date: 7 Dec 2004 05:16:19 -0800

Dear all,
I have the following issue:

I am using gcc 2.95.3 with Objective-C extensions to compile for the
Sharp C860 (Linux 2.4.18 kernel and glibc 2.2.2).

The code dynamically loads a lot of shared libraries through dlopen()
but spuroiusly runs into an "Illegal Instruction".

Several tests have reduced the code to a simple main() function that
dlopens several system libraries and then three of my own shared
libraries. The strange things are:
* it is not repeatable. Sometimes, the Illegal Instruction comes on
the first library. Starting again (even in a while true loop) makes
the first and second load and it fails on the third one. In approx. 1
out of 100 cases it loads all three.
* there is some dependency on the code included in the library - but
it even fails with a nearly empty shared library.
* it makes no difference if RT_LAZY or RT_NOW is specified
* -rdynamic also makes no difference
* running under gdb is also strange. Sometimes it loads without
problems, sometimes it fails. The stack backtrace issues a "can't
access memory location". info share sometimes fails as well. If not it
shows that the failing library has been loaded.
* writing a core dump also changes the gdb output.
* the Illegal Instruction occurs within dlopen()
* it *might* come from the _init code but I was not yet able to
verify. Adding debug code to the objc runtime (which I assume is
called from _init) was not called before the Illegal Instruction
appeared
* the strange thing is that the same code runs on a SL5500 without
problems
* The Qtopia system used on the Zaurus also relies heavily on shared
libraries and seems to work

So I have several hypotheses:
* there is a bug in the glue code for _init
* there is a bug in the dlopen() function (where can I find source
codes?) which depends on the size or alignment of the loaded library
* there is a Kernel bug behind dlopen() which fails to load the
correct page
* the CPU cache is not properly managed when code is swapped in

What I would really appreciate are any hints, helps and workarounds on
that issue.

Many thanks,

hns
http://www.dsitri.de

Relevant Pages

  • Re: Crashing dlopen() on Sharp Zaurus C860
    ... > The code dynamically loads a lot of shared libraries through dlopen ... > dlopens several system libraries and then three of my own shared ... > the first and second load and it fails on the third one. ... > out of 100 cases it loads all three. ...
    (comp.os.linux.embedded)
  • Re: Crashing dlopen() on Sharp Zaurus C860
    ... > The code dynamically loads a lot of shared libraries through dlopen ... > dlopens several system libraries and then three of my own shared ... > the first and second load and it fails on the third one. ... > out of 100 cases it loads all three. ...
    (comp.os.linux.development.system)
  • Re: D2005 - Solution to Start up times etc
    ... executable and libraries, and therefore, in general, the smaller the lines ... if an application loads very quickly then I infer that the ... Do you disagree with this chain of reasoning? ... specifics so that I can improve my reasoning ability. ...
    (borland.public.delphi.non-technical)
  • Crashing dlopen() on Sharp Zaurus C860
    ... The code dynamically loads a lot of shared libraries through dlopen ... the first and second load and it fails on the third one. ...
    (comp.os.linux.embedded)
  • Problem for a shared-library expert
    ... This executable also loads a number of third-party shared libraries. ...
    (comp.os.linux.development.apps)