dbirchfield@asu.edu

I'm instantiating a number of maxbox objects via mxj and occasionally get the following output in the max window that is not printed by my code:

error: (mxj) Constructing object from unknown thread!!!This is no good. How did it happen!

it's a bit sporadic so I've had trouble identifying the particular object that is giving the problem. however, it does appear to potentially be related to the instantiation of a mysql database connection in my java code.

I'm also running in to sporadic but relatively frequent hard crashes when I remove objects that are related to jitter gl texture maps. Could these issues be related somehow? or perhaps just a coincidence?

error: (mxj) Constructing object from unknown thread!!!This is no good.  How did it happen!

it's a bit sporadic so I've had trouble identifying the particular object that is giving the problem.  however, it does appear to potentially be related to the instantiation of a mysql database connection in my java code.

I'm also running in to sporadic but relatively frequent hard crashes when I remove objects that are related to jitter gl texture maps.  Could these issues be related somehow?  or perhaps just a coincidence?

mxj-error-message

> I'm also running in to sporadic but relatively frequent hard crashes when I remove objects that are related to jitter gl texture maps. Could these issues be related somehow? or perhaps just a coincidence?

who knows? Unfortunately without a way of reliably reproducing the

crash we can only speculate. The mxj error msg you quote is a

surprise - I think something somewhere is pretty broken for that text

to be showing up in the max window. if you can isolate the bug any

> I'm also running in to sporadic but relatively frequent hard crashes when I remove objects that are related to jitter gl texture maps.  Could these issues be related somehow?  or perhaps just a coincidence?

who knows?  Unfortunately without a way of reliably reproducing the
crash we can only speculate.  The mxj error msg you quote is a
surprise - I think something somewhere is pretty broken for that text
to be showing up in the max window.  if you can isolate the bug any
more we'd definitely appreciate it.

a bit more testing reveals that the the two issues are apparently not necessarily related.

My code generates the max window 'error (mxj)' message whenever I do the following:

1) I write and save a max patch that contains a single box : mxj net.multi.recv

2) from within my other mxj 'instantiator' code, I add several MaxBoxes to the patcher that yield no errors.

3) when I add the max box that was created in (1) it generates the error every time. btw. if I just add the (1) object by hand in a new patcher, no error message appears.

3) when I add the max box that was created in (1) it generates the error every time.  btw. if I just add the (1) object by hand in a new patcher, no error message appears.


the problem is that somehow the boxes are being instantiated from a 

the problem is that somehow the boxes are being instantiated from a  
thread other than the main app thread
or the scheduler thread.

deferlow does indeed resolve both the add and remove problems it appears - sorry for the newbie mistake.

is there any way to get notification that the Executable function has executed? currently I deferlow and then have a pause function to wait 500ms to ensure that the add/remove successfully occurs. I found that short pauses work most of the time but can lead to null pointer exceptions when trying to connect to an newly added object when the deferlow hasn't yet executed.

if the deferlow command would return a result, I could insert a while loop in my code to wait until it has executed before proceeding. Is there another preferred method to work around this issue? my solution feels a bit like a kludge.

is there any way to get notification that the Executable function has executed?  currently I deferlow and then have a pause function to wait 500ms to ensure that the add/remove successfully occurs.  I found that short pauses work most of the time but can lead to null pointer exceptions when trying to connect to an newly added object when the deferlow hasn't yet executed.

if the deferlow command would return a result, I could insert a while loop in my code to wait until it has executed before proceeding.  Is there another preferred method to work around this issue?  my solution feels a bit like a kludge.


sorry - I also meant to offer another solutions which would be to check if the new object is null or not before proceeding, but that still doesn't seem ideal.

defer is asynchronous and there is no notification system currently 

    MaxSystem.deferLow(new Executable(){

        //you need to make sure you are calling this from something other 

        //thread(which from your problem it seems like you are) otherwise 

        }catch(InterruptedException ie)

            ie.printStackTrace();

This is just crap email client coding and not tested but maybe it 

defer is asynchronous and there is no notification system currently  
in place.
you could maybe spin lock.

private boolean executed = false;
...
...

private void execute_function()
{
	executed = false;
	MaxSystem.deferLow(new Executable(){

		public void execute()
		{
			do_my_thing();

			executed = true;
		}
		});
	while(!executed)
	{
		//you need to make sure you are calling this from something other  
than the main
		//thread(which from your problem it seems like you are) otherwise  
you will never exit.
		try{
			Thread.sleep(5);
		}catch(InterruptedException ie)
		{
			ie.printStackTrace();
		}
	}
}

This is just crap email client coding and not tested but maybe it  
gives you an idea.
topher


mxj error message