Conference azur::mcc

Perhaps someone will have some ideas on this, but we don't have
anyone assigned to track problems in the field test code any more.

    Hello,
    
    We've now upgraded to V1.2, we still have the problem described in the
    base note. Any idea on where to look, additional traces we could turn
    on etc.. ?
    
    �HR.

Hello.

I will enter a qar and take a look at it, but I have other urgent work ahead 
of it.  In the mean time, please confirm that the 5 after the [ 6093 ]
is a misprint.  It should be a (.  

Regards,

Ruth Kohls


    [  0 ]  ( 
        [   1 ]  (	
             [    6039 ]  5	      
                     [  1 ]		34  --  4	     
     		     [  3 ]		00	      
     		     [  4 ]  (		  
    			[  1 ]  (		       
    			    [   1 ] 		02		      
     			    [   2 ]             02 
    			   ) 
                    ) 
                ) 
           ) 
      )

entered as qar 3415 against the exec in mcc_internal. RK

    Re: .3:
    
    Yep, it's a typo ! on french keyboards, 5 = Shift '(' !!
    
    By the way, I've never used QAR, how do I get informed on the status of
    the QAR ?
    
    Thanks for your time,
    
    Philippe.

When a QAR from a note is answered, the answer is usually cross
posted to the original note.

To check directly you would need a QAR system account  (don't bother
at the moment; we may be switching QAR systems soon).

-- Erik

Just a thought.  Have you tried increasing the STACK memory that your
application has available?  Those ILV calls need an additional context area,
which is on the stack, for the list mode manipulations.

Ruth K.

    Ruth,
    
    I asked my customer to increase the stack size. He set it to the
    maximum value using the "limit" command. I am not an expert on how to
    set stack sizes, is this the way to do it ?
    
    The problem is still there....
    
    �hR.

>    I asked my customer to increase the stack size. He set it to the
>    maximum value using the "limit" command. I am not an expert on how to
>    set stack sizes, is this the way to do it ?

I think yes, its a csh command, look in the Man pages for more. The expert 
I asked said they should use "setrlimit" (in my ancient Ultrix32 manuals, 
these are in volume 2, system calls).  To me, it looks like the difference is 
an internal system call (setrlimit) vs. a csh command (limit) with similar 
effects but different scope of application.

The scope may be a factor.

My expert also says, the application may have other structures that 
are getting in the way of increasing stack (such as shared memory).
 
I will keep looking and asking.

Ruth K.

  
    I have also seen this problem.
    The funny thing is that if the ***ilv_*** instructions are part of a DECmcc
    MM and the Stack size defined for this MM, then the execution is OK.
    The same code, when being linked to "callable mcc" fails.

    What I understand of it, is that when this instruction is executed in the
    MM, the thread which executes has been created with an accurate
    stack size.
    When running as a separate program, the thread that executes the
    code is that of the main program, that is, the initial thread (or that
    of the main program). There is no multithreading in that part of
    their code. 
    So the solution would be to dimension the thread for the main program, so
    I've told them to try the setrlimit service.
        
    One possible alternate solution that I see is to run the decode/encode ilv
    part of the program in a brand new (created) thread with an accurate
    stack size. Correct ?
    
    Florence

Florence,
  
>    I have also seen this problem.
>    The funny thing is that if the ***ilv_*** instructions are part of a DECmcc
>    MM and the Stack size defined for this MM, then the execution is OK.
>    The same code, when being linked to "callable mcc" fails.

Thank you for entering the discussion! 
ILV is designed to use only the memory given to it by the caller or the
stack.  If the caller gives permission, it may re-allocate the data buffers.
The ILV calls reported in .0 do not involve  the latter sort of buffer,
they involve moving context pointers and allocating additional, temporary,
context areas on the stack.  This, and the reported error message is why 
I believe that stack memory in the single threaded application is the problem.

>    What I understand of it, is that when this instruction is executed in the
>    MM, the thread which executes has been created with an accurate
>    stack size.

>    When running as a separate program, the thread that executes the
>    code is that of the main program, that is, the initial thread (or that
>    of the main program). There is no multithreading in that part of
>    their code. 
>    So the solution would be to dimension the thread for the main program, so
>    I've told them to try the setrlimit service.
 
Looking in the Man pages at setrlimit and sbrk, I think that the using the
setrlimit function in the single-threaded application will increase the 
stack that that program is _allowed_ to use.  I think that the brk or sbrk
functions must then be called to actually add to the stack.

You might also try using the csh service "limit" to increase the stack
size granted to all processes and their children, before testing. However, I
think this has been tried. (see the previous replies).

I am NOT sure, this is my interpretation of the man pages.  I hope someone
will either confirm or correct me.
       
>    One possible alternate solution that I see is to run the decode/encode ilv
>    part of the program in a brand new (created) thread with an accurate
>    stack size. Correct ?
    
Probably, but it ought not be necessary. 

I would look at the current stack size and at what is on the stack now.

(The structures that ILV needs are not large, and it doesn't need that many.  
In the examples given in .0, the additional ILV context area size requirement 
is certainly less than 1 K, and I would not be surprized to find that 
ILV's additional stack requirement was around 1/2 K.) 

What I would look for is large data structures, such as maximum sized
Latin1Strings (65535 bytes), allocated on the stack.

Also, a core dump of the problem to look at would be nice. To get that:

setenv MCC_LOG 0x40000 
and then create the crash.
(note, that is Hex 40 000)

Please, do not post a core dump in this notes file, and do not mail me a core 
dump!  Send me mail saying where I can copy it from!

Here's hoping were on the right track.

Ruth Kohls
(TOOK::KOHLS)

    Ruth,

    Thanks for you clear explanations. It is possible that they allocate
    Latin1Strings on the stack.
    The use of the setrlimit service did solve their problem.
    About the core dump, if it is usefull for you, I can see with
    P. Roggeband how you can get one (he is geographically near the
    customer, I am not;
	and also you'll be sure I will not mail you a core !!!!     :-) ).
    
    Florence
    

Hello, Florence,

>    The use of the setrlimit service did solve their problem.
Thank you, that's good to know.

>    About the core dump, if it is usefull for you, I can see with
>    P. Roggeband how you can get one (he is geographically near the
>    customer, I am not;
I mailed him a request for a core dump last week. I'm not sure how much use
it would be now--your customer could probably better use the time and space
figuring out why the stack size was a problem. (Could be anything from the 
kernel configuration to simple over-use of stack.)


>	and also you'll be sure I will not mail you a core !!!!     :-) ).

Well, I was pretty sure about you... (;-))

Thanks again, 

Ruth K.

    The problem is back ! What is the status of this QAR ?
    
    PhR.

The fact that setrlimit was used to get around the problem in V1.2, and this is
a default rather than thread stack,  indicates an enormous stack consumption
probably associated with placing MCC_T_Latin1string datatypes on the stack (these
are defined as char[65536]).

It would appear that some slight increase in V1.3 stack usage has brought the 
problem back.   I think at this point the source program should be changed to
fix the problem.