1833046
Members
2636
Online
110049
Solutions
SOLVED
since you dont have a debuggable library, you have may to do some assembly level debugging, looking at some instructions before and after this point along with register values etc.
of course you are always at an advantage if you know what exactly you want to achieve when you make a call to this library function.
since there is no single remedy for SIGBUS's, each has to be analysed in its own context.
--
ranga
[i work for hpe]
of course you are always at an advantage if you know what exactly you want to achieve when you make a call to this library function.
since there is no single remedy for SIGBUS's, each has to be analysed in its own context.
--
ranga
[i work for hpe]
gdb is sufficient as a tool as long as you can follow the disassembly and make out what is going on.
--
ranga
[i work for hpe]
--
ranga
[i work for hpe]
has this API call ever worked for you, say in a different application etc ? have other API calls to this shared library worked ?
make sure you are using a published API (one that has prototypes declared in a header file, for example), follow the prototype and documentation if any. the shared library's functionality (at least for this API) may require that you should call some initializer function before using any API.
there are the other usual catches - a shared library built with aCC's '-AA' option cannot be used with a program or shared library built without that option. the aCC folks say you should use '-mt' if you are building for a multi-threaded process.
then there *may* be issues if the vendor library was built with (old?) gcc/g++, especially if the library was not built with libgcc.a archived into it and depended on the program to be linked with libgcc : constructors for static global objects in shared libraries may not have been invoked, (as that is usually handled by the runtime support library - like aCC's libCsup). i am saying all this about initializers because the faulting routine is called "pack" - likely to be accessing some RPC data structure - and SIGSEGV indicates faulty memory acess, probably through an uninitialized pointer.
you can try seeing what exactly is happening at the faulting address : e.g. gdb's "x/i $pc" will show the instruction, then you can examine the memory addresses and registers referenced in that instruction to see what is obviously wrong. that kind of debugging *may* give you clues but you may also not get anywhere with it. if you want to do it, keep the latest copies of the gdb manual and the PA-RISC runtime architecture documents handy.
--
ranga
[i work for hpe]
make sure you are using a published API (one that has prototypes declared in a header file, for example), follow the prototype and documentation if any. the shared library's functionality (at least for this API) may require that you should call some initializer function before using any API.
there are the other usual catches - a shared library built with aCC's '-AA' option cannot be used with a program or shared library built without that option. the aCC folks say you should use '-mt' if you are building for a multi-threaded process.
then there *may* be issues if the vendor library was built with (old?) gcc/g++, especially if the library was not built with libgcc.a archived into it and depended on the program to be linked with libgcc : constructors for static global objects in shared libraries may not have been invoked, (as that is usually handled by the runtime support library - like aCC's libCsup). i am saying all this about initializers because the faulting routine is called "pack" - likely to be accessing some RPC data structure - and SIGSEGV indicates faulty memory acess, probably through an uninitialized pointer.
you can try seeing what exactly is happening at the faulting address : e.g. gdb's "x/i $pc" will show the instruction, then you can examine the memory addresses and registers referenced in that instruction to see what is obviously wrong. that kind of debugging *may* give you clues but you may also not get anywhere with it. if you want to do it, keep the latest copies of the gdb manual and the PA-RISC runtime architecture documents handy.
--
ranga
[i work for hpe]