This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Memory leak in ecosynth in abnormal situation.
- From: Bart Veer <bartv at ecoscentric dot com>
- To: john dot carter at tait dot co dot nz
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 21 Jan 2004 13:47:43 +0000 (GMT)
- Subject: Re: [ECOS] Memory leak in ecosynth in abnormal situation.
- References: <Pine.LNX.4.58.0401211428570.6030@parore.tait.co.nz>
>>>>> "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