Re: SIGBUS occuring in shared libray
myfavdepo@gmail.com wrote:
Thanks to both of you for finding time in analysing my query.
I posted this question believing that the Tibco objects are
safe and besides, they have never given us any problems
before.
There's always a first time:-).
As albrecht asked, the msgRep should be initialised safely in
its constructor. Also transport is created prior to this
request.
The most puzzling fact is that it is keeping on working to
process more than 100 or so messages before it crashes.
Because the contents of the first 100 or so messages didn't
contain whatever it is that triggers the bug. Or the bug
depends on some coincidence in timing to be triggered.
And the weird thing was that when i reduced the size of the
message by avoiding:
msg2.updateString ("enddate", szDT);
in the source code, and it worked very comfortably.
Not being familiar with the protocol, I have no idea what effect
this could have.
After that i tried omitting 'msgHdr' and 'msgReq'. Using only
'msg2', i added more fields to it 'msg2'. So after processing
some 300 odd requests it crashed again. When i analyzed the
core file using dbx, and tried the 'dump' command, most of the
variables' addresses were printed as 'invalid' or 'bad'.
Which is what dbx will print if a pointer is bad.
I thought that i've done something really stupid.
But even then how it is working comfortably when the size of the
message is reduced?
Because in reducing the size, you eliminated whatver triggered
the error. (Note that it may---in fact, probably does---take a
combination of factors to trigger the error.)
At last i came to a conclusion that there cud be some memory
access/allocation restrictions for a shared library. Is there something
like that?
I doubt it. Earl Purple said it clearly: you have a misaligned
pointer. I rather suspect either a bug in Tisco itself, or in
your use of the library. In both cases, you really should
address yourself to a Tisco group, or Tisco's technical support.
(Note that it is easy to get a misaligned pointer if the code is
using a na?ve implementation for serializing/deserializing
binary data.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]