@emendes 

From help it says

"Note: In some cases, the execution may not abort at exactly the time limit imposed, but will abort as soon as it can do so safely.  This can happen when execution is in critical sections of certain built-in routines."

This is what happened to me today: It hanged at iteration 2225. (the loop always hangs at some iteration).

I left home and came back later. It was still hanged. Waited more and suddenly after 2 hrs, it went to the next iteration on its own !

Even though the timeout is only 30 seconds on odetest.

Then I noticed it is taking very long time on the next one as well. So I did not want to wait another 2-3 hrs. I stopped maple and started it again and run the loop again from where it hanged and it finished the remaining 300 or so iterations in less than 15 minutes. 

When it starts, it is very fast. The hang happens always near the end of long run.  Seems like memory problems. mserver.exe was not doing anything at all when this happens. No changes in memory use and zero CPU.

When it hanged with you, try to leave it for few hrs and see if it go to next iteration on its own.

I tried changing timeout to 1 minute, 2 minute, etc.. it still hangs at somepoint. One rule of thumb I noticed is the the smaller the timeout, the less likely it will hang. But this is no guarantee.

Maplesoft clearly does not do stress testing on its software. They only do unit tests on individual functions and if each function works correctly, that is it.

But they should also test the whole system, using stress testing, by running long loops over and over and someone inside Maplesoft will see these problems. 

I've seen these hangs with timeouts for years now.  When I use Mathematica, it never once hanged on a timeout. I run longer jobs with Mathematica, it never failed not to timeout at the exact timeout limit set.  Why is it hard to do this with Maple, I do not know.  

@Carl Love 

>>>> Do you put the restart in its own execution group? 

Yes.

Ok. It hanged now. At same place. In the worksheet, which is hanged now, it says at the bottom:

        "before calling odetest with time limit"

Is the last print on the screen as of 20 minutes ago. At iteration 2225.  The timelimit is only 30 seconds. 

Looking at task manager, I see 2 mserver.exe there. with ZERO cpu and no memory change at all. Here is screen shot

I will leave it hanged like this for now, as I have to rush for an errand. When I come back later in the day, will see if I can find anything more. 

So mserver.exe is not doing anything at all. It clearly hanged inside the odetest with timeout not firing. 

@Carl Love 

I started the loop again now. it will take few hrs. when it hangs, (and almost sure it will, since it did each time before), I will record what mserver is doing then).  I will check on it in the morning.

@Carl Love 

Yes, I meant Maple gave no syntax error.  

But this is strange if it just ignores it. I thought the parser will have complained if  one uses invalid option. 

Maple should do better syntax checking in this case. 

@Carl Love 

>>>> I can't find any documentation on an assume option to odetest. Where did you see it?

I did not see it anywhere, I just tried it and it worked, so switched to it.

But I will try now to change it back to the syntax you just showed, since it allows me to use assuming with a list also, which is what I wanted. And assuming works, but for some reason, assume=[] does not like the list I have.

thanks.

@Carl Love 

>>>>    You say that when you press "interupt the current operation", it doesn't work.

But I said  

                   "interrupt the current operation". This does stop the hangs.

it works. i.e. the hangs stops. I read what  I wrote again, I do not see where I said it does not work.

After the hanged worksheet stop, I do restart and starts the loop again. It hangs again. That is what I meant.

Only when I restarted Maple itself, does the hang not return.

>>>>>> All that you need to do is kill the kernel from Windows Task Manager

Yes, I know I could do this. The problem is that there are a number of mserver.exe and I do not know which one. So easier just to restart Maple. I always save my worksheets before I run the main loop, since I know Maple will always hang at some point. 

If you want same order each time, you can sort them as given here

https://www.mapleprimes.com/questions/119852-Order-Of-Eigenvalues-In-LinearAlgebra

There must be a bug in your Maple version. Your proc is not defined to take in any arguments.

Please report this to Maplesoft support. This should not have worked. i.e. it should not have given the result you show. Here is what it gives on Maple 2020.1

restart;
norm3d:=proc() local a,b,c;sqrt(a^2+b^2+c^2) end;
norm3d(3,4,5);

This version works

restart;
norm3d:=proc(a,b,c) 
   return sqrt(a^2+b^2+c^2) 
end;
norm3d(3,4,5);

try to include all the code.

@Carl Love 

I am sorry, but when I tested it, it is not working when the return value is used inside another proc

boo:=proc()
 return 'NULL';
end proc;

foo:=proc()
  local a;
  a:=boo();
  if evalb(a=NULL) then
     print("a is null");
  else
     print("a is not null");
  fi;
end proc;

foo()

        "a is not null"

it should print "a is null"

it only works if the check is done at global level:

a:=boo();

if evalb(a=NULL) then
     print("a is null");
  else
     print("a is not null");
fi:

   "a is null"

So I am afraid this solution would not work for me as it stands, as I am going to use this deep inside module's proc. I do not know why it works only on global level. I think this is related to automatic evaluation at gloal level vs. inside a proc. I got bitten by this before.

I found if I add an eval, then it works:

boo:=proc()
 return 'NULL';
end proc;

foo:=proc()
  local a;
  a:=boo();
  if evalb(eval(a)=NULL) then
     print("a is NULL");
  else
     print("a is not NULL");
  fi;
end proc;


foo()

And now it prints correctly

        "a is NULL"

Or simply  

        if eval(a)=NULL then

will work also. But eval is needed since inside proc.  This is same problem I had in

https://www.mapleprimes.com/questions/230151-How-To-Distinguish-Between-Unevaluated

Where eval was needed when inside a proc() vs. on global level.  Maple has some strange evaluation rules.

@acer 

thanks. But repeated calls keep increasing the counter used. For example

This seems to be undocuments function? I saw reference to it at 

https://www.math.ubc.ca/~israel/advisor/advisor6/h1r1.htm

Is there a way to "reset" this counter so it does not keep increasing for each call? I have loop of 1,000's of ode's, so it will look bad after a while if this counter keeps increasing.

I can reset it back at end of the proc for example, so next call it starts again at zero. Then this might work.

@rlopez 

Yes, you are correct. That is what I meant to say, but was lazy and did not write it as precise as you said it.

@Carl Love 

The code that set currentdir() and libname was inside an exported proc, just like I showed in the example skelton I posted.

To verify, I just added these 2 lines back, build the mla and I get the error again. Removed these 2 lines, the error went away. These are lines

local main_dir:="C:/tmp/current_version/";          

currentdir(main_dir):   
:-libname := main_dir, :-libname;

These are the first thing I was doing in the exported proc.

All what I know, If I remove these, it works OK. If I can make a small example that shows this error will post it.

@Carl Love 

thanks for the additional info. If I get some free time, will try to make minimal example. 

@acer 

This was meant as skelton to show the problem cause. ofcourse there is a end module there. 

The code is over 10,000 lines long, and to make a MWE that will reproduce the problem might take me long time. I just showed what was the cause and to say it is resolved once I removed the re-setting of libname inside.

It is not critical for me to know the real cause, as I will not do this resetting of libname and setting currentdir() again inside the module. I will do this only from outside from now on.

It seems related to duplicate entries on the libname  that confused Maple. 

If I get some free time, I will try to reproduce this using small example.