Re: exception propagated across module boundary, type unknown

[ben mitch]

Paul Pluzhnikov wrote:
> ben mitch <news@net.benmitch> writes:
>
>> we are currently porting an application to linux and are having a
>> problem.
>
> Instead of re-posting the exact message you posted to c.o.l.d.apps,
> you should have at least answered the questions that were asked
> there (or you'll get the exact same suggestions, wasting everyone's
> time).

i didn't post the same message, i edited with reference to the comments 
i was given: updating "gcc" to "g++"; making clear the relationship of 
the executable with matlab; changing the title and removing my 
speculation to reflect your own comment that my suggestion was 
incorrect; making inter-module dependencies explicit in response to 
somebody's comment about circular references being a non-starter; and 
adding an explanatory note of what i meant by 'calling the executable' 
in response to your(?) question asking what i meant by this. my 
apologies if i didn't provide the information that you had in mind, but 
i did try :) - please don't consider me ungrateful, i am very g. for any 
and all help!

more info follows...

> What was the *exact* compile and link command?

[core] (no dependencies)
g++ -D_GNU_SOURCE -Werror -pthread -O3 -ffast-math -fPIC -shared 
-Wl,--export-dynamic core.cpp -o ~/bin/libcore.so

[process] (depends: core)
g++ -D'C_EXPORT=extern "C"' -D_GNU_SOURCE -Werror -pthread -O3 
-ffast-math -fPIC -shared -Wl,--export-dynamic core.cpp -I~/bin 
-I$(PATH_MATLAB)/extern/include process.cpp -Wl,-rpath,$(PATH_BIN) 
-L$(PATH_BIN) -lcore -L$(PATH_MATLAB)/bin/glnx86 -lmx -o ~/bin/process.so

(where C_EXPORT is used for the CreateObject() function to cause it to 
have no name decoration)

[manager-parts] (depends: core)
FLAGS = -D_GNU_SOURCE -Werror -pthread -O3 -ffast-math -fPIC -shared -c 
-I~/bin -I$(PATH_MATLAB)/extern/include
g++ $(FLAGS) a.cpp -o ~/temp/a.o
g++ $(FLAGS) b.cpp -o ~/temp/b.o
g++ $(FLAGS) c.cpp -o ~/temp/c.o

[manager] (depends: core)
g++ -c -I$(PATH_MATLAB)/extern/include -DMATLAB_MEX_FILE -fPIC -ansi 
-D_GNU_SOURCE -pthread -O3 -ffast-math -DNDEBUG manager.cpp -o 
~/bin/manager.o
(this file included with every matlab "mex" compile...)
gcc -c -I$(PATH_MATLAB)/extern/include -DMATLAB_MEX_FILE -fPIC -ansi 
-D_GNU_SOURCE -pthread -fexceptions -m32 -O -DNDEBUG 
$(PATH_MATLAB)/extern/src/mexversion.c -o ~/bin/mexversion.o
g++ -O -pthread -shared -m32 
-Wl,--version-script,$(PATH_MATLAB)/extern/lib/glnx86/mexFunction.map 
-Wl,--export-dynamic ~/temp/*.o -Wl,-rpath,~/bin -L~/bin -lcore -ldl -o 
~/bin/manager.mexglx  ~/bin/manager.o ~/bin/mexversion.o 
-Wl,-rpath-link,$(PATH_MATLAB)/bin/glnx86 -L$(PATH_MATLAB)/bin/glnx86 
-lmx -lmex -lmat -lm -lm



> What does "calling manager" second time mean?

i start matlab. i call the manager once, as in from matlab i run 
"manager(pars)", which invokes the matlab mex-file manager.mexglx (calls 
a function in this shared library file, essentially, i think). the 
manager runs, performs the steps listed below, then returns control to 
matlab. i assume it and the core and the process remain resident. i then 
call it again exactly as before (w/o restarting matlab). i assume there 
won't be the same linkage steps performed, since the core/process are 
already loaded and linked. the exception is now caught correctly. if i 
restart matlab, the exception is uncaught on the first run after restart.

* start manager
* manager calls function exported from process.so CreateObject() to 
create an object X, which is derived from an interface defined in core
* manager spawns a new worker thread (posix)
* worker thread calls member function of X
* member function of X throws a custom exception, defined in core.so
* exception propagates back up to manager (in worker thread)
* exception type is unrecognised (i.e. is caught by catch(...))


> Is there any difference between LD_DEBUG=... output on first
> (failing) and second (successful) run?

i had thought this was not possible to do originally since i am calling 
the executable from matlab. i have tried to set the LD_DEBUG var from 
within matlab, but i can't get the syntax right. the var gets set for 
the duration of a call to the OS, then when i am back in matlab to make 
the call, the var is no longer set. i thought i could not set the var 
and then invoke matlab since then how could i interact with matlab? this 
is why i did not post a comment wrt this. however, i thought of a 
solution this morning - i can set the var and invoke matlab using a 
command line switch which means 'run this after starting', then i don't 
need to interact. so i set matlab to call the manager two times after 
starting, then exit.

this generates 230MB of output, 99.9% of which happens before the 
manager is invoked. bizarrely, no linking appears to be performed 
throughout the time bracketed by the first invocation of the manager and 
return from the second invocation. previous to matlab even starting, 
functions within the manager/core/process application appear to be 
resolved - does this mean linux caches the libraries that an application 
uses, and pre-resolves them? in any case, it means that that technique 
appears to give no helpful information, or none that i can understand (i 
will not attach a dump :)


Meanwhile, this just in... after performing two runs in matlab, so the 
exception is now being recognised correctly, the following 
actions/effects are noted:

* rebuild [manager] : next run, exception recognised correctly
* rebuild [manager-parts], [manager] : next run, exception recognised 
correctly
* rebuild [process] : next run, exception recognised correctly
* rebuild [core] : next run, exception recognised correctly
* rebuild [everything] : next run, exception recognised correctly
* restart matlab : next run, not recognised

that's a bit unexpected. i guess previously we were dropping out of 
matlab every time to rebuild the manager, and it was _that_ that was 
'restarting' the cycle, not the manager rebuild (we're now rebuilding it 
in a separate shell - hope that doesn't obfuscate anything). still, the 
exception is being unrecognised within our app rather than anywhere 
related to matlab, so the problem i think remains unchanged, just the 
evidence is a little different.

but - if the output from ld() indicates that no linking is being 
performed between the two invocations, what can be going on?

cheers
ben