[25584] in Athena Bugs
Re: sun4 9.2.28: matlab
daemon@ATHENA.MIT.EDU (Alex T Prengel)
Wed Apr 7 13:49:36 2004
Message-Id: <200404071749.i37Hn2BT018618@dit.mit.edu>
To: Asanka C Herath <asanka@mit.edu>
In-reply-to: "[25572] in Athena Bugs"
In-Reply-To: Your message of "Tue, 06 Apr 2004 18:06:42 EDT."
<Pine.GSO.4.55L.0404061754540.10578@no-knife.mit.edu>
Date: Wed, 07 Apr 2004 13:49:02 -0400
From: Alex T Prengel <alexp@mit.edu>
cc: alexp@mit.edu
cc: jamous@mit.edu
cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
>> There's no easy way around this, other than unwrapping Matlab which we
>> don't want to do. If it's important that you be able to run this so
>> you can debug someone's problem, I can temporarily make it possible
>> for you to access an unwrapped copy (for a few hours or so).
>
>This actually came up as an OLC question. The user wants to debug MEX
>files. We suggested a workaround for him which is to set MATLAB_DEBUG by
>hand and attach the debugger to the running Matlab process (which
>"works-for-me" under Solaris, but has problems on Linux).
>
>Since unwrapping the binary doesn't seem to be an option for general
>users, I think a good workaround should be documented and made available
>to users.
This seems reasonable to me- would you care to suggest wording? Daniel and
I don't have much experience attaching to running processes so I think
you'd know more about this than we do. If you can shed any light on the
Linux situation that would be great. If it can't be made to work reliably
or at all on Linux I think it would be best to advise users to do it only
on Suns.
Alex
