Conference turris::digital_unix

I'm not sure I understand the question, but that's never stopped me before...
:-)

That error message is returned when the unwinder cannot find a code range
descriptor (crd) that describes the current pc.   

The code range descriptor lists are built using the __exc_add_pc_range_table()
routine.  That routine is called (indirectly) from a .init routine written
by the linker.   The linker adds that routine only if it sees that the
image needs exception handling - which will be true if the image is
a shareable object, or a -call_shared object, or if the non-shared 
executable includes a reference to the _FPDATA_SIZE special symbol.
crt0.s (__start) is what calls the init routines.

So, if you have an alternate crt0.s, or you are somehow inhibiting the
creation of the .init routines in the linker, or if you are adding code
on the fly and not calling the __exc_add_pc_range_table() routine, you 
can get that error...

Does that answer the question?    

Any chance that __exc_add_pc_range_table() needs to call malloc()?  If so, then
the first call to exc_capture_context() would be issued before the first call to
__exc_add_pc_range_table() returned, in which case there would be no PC range
enclosing the current PC, and that error would result...

>Any chance that __exc_add_pc_range_table() needs to call malloc()?  If so, then
>the first call to exc_capture_context() would be issued before the first call to
>__exc_add_pc_range_table() returned, in which case there would be no PC range
>enclosing the current PC, and that error would result...


The behavior which I see can be explained by the above message. I see at leas 7
mallocs befor the exc_capture_context() rtn can be called cleanly. How can one
figure out that __exc_add_pc_range_table() has been already called and code range
descriptor lists were built? Or should I call it myself?

>> Serge

>Any chance that __exc_add_pc_range_table() needs to call malloc()?

Duh.  Yes, it does.  I think Webb has hit the nail on the head. 

So, how to solve the problem? Any documentation (man pages are not suficient)?

The problem is that there aren't any 'hooks' in the exception system
that indicate it is 'ready to go' - it's an open ended process.   Things
can be added (and removed) at any time.  (for instance, dlopen() will cause
more calls to add_pc_range() for the text in the dlopen'ed library). 

I don't believe there is any general solution to this issue.   If you
'know' in some way that all of the code that your application is present,
then you could set a flag at that point.   (For instance, at the time
main() is called from __start, all of the libraries specified in the static
list (and their dependencies) will have been loaded and their init routines
run - if you application does not call dlopen() then you can be assured at
this point that any calls to your malloc can safely query the exception system.)

Does this help?

Thank you for the reply.

> Does this help?

Unfortunately it cannot solve all related problems. I'll try to figure out
something else.

Actually, I think (but my head is fuzzy) that all you need to do is catch
-recursive- calls to malloc().  (This is easier to do if you don't care about
threads, but you can also make it work for threads with thread-specific
data.)  So, if you get a recursive call to malloc() -- i.e., a call to
malloc() while you're in the process of generating a stack track for a
previous call -- skip over generating the trace of the recursive call.
You'll loose some calls this way, but you could note them, and I don't see
that you have much other choice.


					Webb

I think that it works in an opposit direction. There are no recurcive calls to
malloc. The exc_... is probably used recurcively but I cannot catch that. 

I need to create my own version of libexc. Can I get sources for libexc anywhere?

>I need to create my own version of libexc. Can I get sources for libexc 
>anywhere?

If you get a source kit, you should be able to, after some fiddling.   I'm
not sure how to get one - maybe someone else will pipe in...

    I've deleted my previous answer, as it wasn't (as always) totally
    correct.
    first, i wouldn't use your way unless you've got a specific reason.
    gathering data about the alloc family is a quite simple tasks 
    with ATOM. There was also some sample code about stackframes,
    at least in th eearly atom kits (i think it was called paltrace)
    on the other hand, if you want it, and you are just looking for
    a flag/var telling you the needed application initialization 
    I would append my only shared library as the last library on the
    link line, and set the flag in the libs __init routine. Due to th erules
    depicted in the programmers guide (section 4.2.3 if I remember right)
    the _init routines are called from left to right. so your lib is called
    last, but still before main gets invoked. (at least should be, I
    haven't tried to call exc routines out of the init routines, but its
    definitly before main).
    
    if you are interested in the loader activities,before your program
    is actual started, play around with _RLD_ARGS -debug option, but 
    that's only due to the malloc invocatons mentioned some replies 
    before. you won't see them all, but sometimes this option helped
    me debugging.
    
    good luck
     Pit