Iain MacDonnell wrote on 03/15/06 07:49 PM:
Karsten Ohme wrote on 03/15/06 07:08 PM:
Iain MacDonnell wrote:
I've run into a problem with two different applications that link to
libmusclecard. One of them is muscleTool-2.1.0, and the other is a
proprietary tool that's not OpenSource, but the symptom is the same -
ie. they both get stuck in an endless loop when trying to parse XML
files, during yylex().
Eg. When I run muscleTool and try to do "tokens", it "hangs":
blue-midget# /opt/ITmuscle/bin/muscleTool
MuscleCard shell - type "help" for help.
muscleTool > version
muscleTool version: 2.1.0
Copyright (C) 1998-2002 David Corcoran
Copyright (C) 2003 Ludovic Rousseau
Copyright (C) 2004 Toni Andjelkovic
Copyright (C) 2005 Karsten Ohme
muscleTool > tokens
I can see that the stack trace is:
08053b29 yylex (8047dbc, d1faab44, d1fbb170, d1fa7158, d1fbc16c,
d1fa9daf) + 545
d1fa9e79 LTPBundleFindValueWithKey (8047225, d1fbc16c, 8047063, 0) + d9
d1fa7158 TPSearchBundlesForAtr (804759c, 9, 804737c) + 198
d1fa2e42 MSCListTokens (1, 0, 806fff8, 126) + 272
08055258 doListTokens (d1e987b4, c, 1d, 27, 8047634, 8047962) + 49
08052e78 yyparse (d1fca0e0, d1ffb314, d1ffb840, 8047c38, 0, 6373756d)
+ 717
080535ce main (1, 8047d60, 8047d68) + 12e
08052604 _start (1, 8047e24, 0, 8047e41, 8047e60, 8047e6b) + 80
The other application also hangs during yylex() (different type of XML
file being parsed at the time).
In both cases, if I point them at an old libmusclecard.so from
1.2.9-beta7, the problem goes away. I did notice that the older library
(which I didn't build - someone gave me the binary) is linked to
'libl.so' - the Solaris lex library, but my v1.3.x version is not. I
tried forcing it by adding LEXLIB to LIBS in the Makefile, but it didn't
help the actual problem - ie. the endless loop still occurs.
Could this have something do to with the visibility changes? I'm a bit
flummoxed by it... :(
Actually the visibility changes should fix this. And at least on my
Debian they did. There was a problem with the lex parser of muscleTool
and the lexx stuff to parse the XML Info.plist from libmusclecard. I
thought it had something to do with newer gcc versions, because it was
working in former times, but a real reason would be interesting.
Use the tool objdump or nm or whatever to see the exported symbols of
the library. Maybe this can help.
Yeah, I was just thinking along these lines, after sending that message.
I looked at the source for libmusclecard 1.2.9-beta7, and notice that it
does not have a tokenparser.l, so perhaps a new use of (f)lex was added
in a later version, and now that's somehow overriding the parser in
muscleTool (but not doing its job).
I think that visibility works (or doesn't work) differently with the
Sun compilers (vs. gcc). Maybe Dr. Ludovic can shed some light on this...
AH-HA! I found this option for Solaris' ld:
-B symbolic
In dynamic mode only. When building a shared object,
binds references to global symbols to their definitions,
if available, within the object. Normally, references to
global symbols within shared objects are not bound until
runtime, even if definitions are available. This model
allows definitions of the same symbol in an executable
or other shared object to override the object's own
definition. ld issues warnings for undefined symbols
unless -z defs overrides.
The -B symbolic option is intended for specialized
dynamic objects and is not recommended for general use.
To reduce the runtime relocation overhead of an object,
the creation of a version definition is recommended.
When I link libmusclecard.so with this option, it seems to solve the
yylex() problem, at least at first glance. I'll dig in more tomorrow
and see if it's really solved the problem, without any side-effects.
Maybe we need to look into a "version definition" for the proper
solution....
~Iain (will sleep better now:)
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
