ben mitch <[EMAIL PROTECTED]> writes: > Paul Pluzhnikov wrote:
> > Instead of re-posting the exact message you posted to c.o.l.d.apps, > > i didn't post the same message, Ah, I apologize -- I should have diff'd them first. > making clear the relationship of the executable with matlab First confusion point: the "manager" is not in fact an executable. It is a shared library just like any other. > > 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). Correct. > the manager runs, performs the steps listed below, then > returns control to matlab. i assume it and the core and the process > remain resident. Correct. > 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. Correct. > the > exception is now caught correctly. if i restart matlab, the exception > is uncaught on the first run after restart. I can't think of any explanation for this ... > > 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 That would be too late: LD_DEBUG is examined only when the process starts. Once MatLab is running, any settings of LD_DEBUG will only affect its children, but not MatLab itself. > 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. All "interesting" linking will happen *before* you see any output from the first invocation of manager. You need to make MatLab print "hello" before invoking manager, then look for symbol bindings between this "hello" and the first evidence that manager is executing. Pay particular attention to symbols that have "<your custom exception>" in their name. > 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? No. You probably just didn't determine correctly where the "MatLab is loaded and now starts running the user script" boundary is. > 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 This is because MatLab doesn't reload "manager", "process" or "core": the old copies are still in-core and are being used. > * restart matlab : next run, not recognised Now you are re-loading the shared libraries, and they fail the same way. This is self-consistent (and consistent with my mental model of what's happening). > that's a bit unexpected. i guess previously we were dropping out of > matlab every time to rebuild the manager Probably Win32 habit -- on Win32 you can't rebuild DLL that is "in execution", so you have to exit MatLab. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
