cobol memory leak when using threads

[Ignacio Javier]

Hi gurus:

I am trying to find where is the error in this code. I just want to create a thread and from the main program, kill it.
I do dat in a loop and the mémory grows and grows. I can se than the tread is beeng killed but i don´t know why the memory is growing.

Could you pleas help me ?

Thanks in advance:

The code :

$set sourceformat"free"
$set REENTRANT"1"

IDENTIFICATION DIVISION.
PROGRAM-ID. prueba_signal.
AUTHOR. Ignacio Javier Sanchez.
DATE-WRITTEN. 06-06-2007.

DATA DIVISION.
WORKING-STORAGE SECTION.

01 flag pic s9(9) comp-5.
01 id-hilo-unix pic s9(9) comp-5 value 0.
01 unix-self pic s9(9) comp-5 value 0.

01 thread-id-p-mixto usage pointer.

LINKAGE SECTION.
PROCEDURE DIVISION.

perform until 1=2

call 'CBL_THREAD_CREATE' using 'HILO-PRUEBA'
0
by value 0
0
0
0
by reference thread-id-p-mixto

call "usleep" using by value 500000
display "hilo nuevo creado.........................."
perform mata-hilo

end-perform
stop run.


mata-hilo.
display "Vamos a hacer un kill sobre el hilo"
call 'CBL_THREAD_KILL' using by value thread-id-p-mixto
.
fin-mata-hilo.


entry "HILO-PRUEBA".
display "soy el hilo hijo"
call "sleep" using by value 300
stop run
.

[Steven E. Protter]

Shalom,

It may not be your code.

It may be a problem with the cobol compiler.

It could also be a system problem. Has the system been patched with a recent bi-annual patch set?

SEP

[Dennis Handly]

Not knowing anything about COBOL since the 1985 Standard, why do you have "stop run" at the end of your "HILO-PRUEBA"?

Is there a way to get the status of your CBL_THREAD_KILL?

If the solution still isn't obvious, you'll have to debug at the C level and use gdb's leak detection and perhaps use tusc.

[Ignacio Javier]

Thanks:

The result of the call 'CBL_THREAD_KILL' is a success. I can see than the thread is not present and so the System shows it.
But the memory grows.....

The stop run is there because i was doing tests. I think it makes no difference in the code.

If i do not kill de thread, it finishes by it self, there is no memory leak.
I have made a work around using a signal that the thread captures and then executes a stop run.

Could you please tell me how can I debug this proces with gdb ? I thought that debugger was for C only.

Thanks

[Dennis Handly]

>I think it makes no difference in the code.

I thought it would stop the whole process. That's what it did in COBOLII/iX.

>If i do not kill the thread, it finishes by it self, there is no memory leak.

Have you created the thread in the right state? If you use don't use detach, you may have to use pthread_join to recover the space?? PTHREAD_CREATE_JOINABLE is the default

>Could you please tell me how can I debug this proces with gdb? I thought that debugger was for C only.

You are imagining you have a COBOL program. You debug in assembly mode. ;-)

You just use:
gdb executable
(gdb) set heap-check on
(gdb) r parms to your program ...

And the end:
(gdb) info leaks

You can download gdb from:
http://www.hp.com/go/wdb

[James R. Ferguson]

Hi:

As I recall, a "STOP RUN" in a COBOL program means immediate termination of everything. There is no cleanup (epilog) code executed.

From that standpoint, I think I would expect any thread or process that had malloc()ed memory to be killed without an opportunity to free() that memory.

Regards!

...JRF...

[Dennis Handly]

>JRF: I think I would expect any thread or process that had malloc()ed memory to be killed without an opportunity to free() that memory.

Except if you terminate the process, the OS frees everything.

[Ignacio Javier]

Hi:

The code is never reaching the point the "stop run." is.
The thread it is waiting 300 seconds and the main process, kills it before it gets to that point.

I i do the following:

entry "HILO-PRUEBA".
display "soy el hilo hijo"
stop run
.

What finishes is the thread and not the hole process. And all the resources ( what it was worth when the thread was created ) are free.

So, the problem begins when you want to finish a thread with the 'CBL_THREAD_KILL' call.

Regards