This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Memory leak in ecosynth in abnormal situation.


>>>>> "John" == John Carter <john.carter@tait.co.nz> writes:

    John> We have found a strong memory leak in ecosynth that occurs
    John> in an abnormal situation.

    John> If we run our application on the synthetic target with --io,
    John> ecosynth starts up and behaves itself.

    John> If we kill our application ecosynth doesn't exit.

This is deliberate. If ecosynth exited immediately then you would not
be able to see any output produced by the application near the end.
The current behaviour means that you get a chance to look at all the
output, save it to a file if desired, etc.

    John> When we rerun our application so there are now two copies of
    John> ecosynth running simultaneously, ecosynth starts leaking
    John> memory at a ferocious rate.

    John> The obvious workaround is "Don't Do That", but it would be
    John> nice if ecosynth was a bit more robust and could handle the
    John> situation gracefully.

    John> Using gdb I can see the leak is somewhere in the .tcl part
    John> of ecosynth, and probably not in the .c part. (A gdb stack
    John> trace it shows it running the tcl interpreter.)

    John> strace'ing it shows that it is repeatedly doing
    John> select,gettimeofday,read,brk

The implication is that the Tcl library is still doing a select() on
the pipe that connected ecosynth to the application, and is getting
confused by the errors. Does the strace output show the file
descriptor being used for the read()? File descriptor 3 should be the
pipe. 

Obviously this should not be happening. In ecosynth.tcl, when an EOF
has been detected it calls:

    fileevent $synth::_channel_from_app readable ""

which should disconnect the channel from the event loop and hence from
select().

Unfortunately I cannot reproduce the problem on the system I am
currently using (Linux == RH9, Tcl is the 8.3.5-88 RPM). I ran the
kernel dhrystone test twice, both of which exited almost immediately,
but left the ecosynth processes running. No sign of any memory leak.
I then ran another application which does some network I/O and waits
for incoming socket connections. Again everything is happy, the
various ecosynth processes are not spinning or leaking memory.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]