Defunct processes

[Mathieu.Dacremont@…]

Using Lyx with RH 7.3. Build from source. After saving the changes in a
document, id do a ps -ae and i see defunct processes :

19047 ? 00:00:11 lyx
19054 ? 00:00:00 lyx <defunct>
19061 ? 00:00:00 lyx <defunct>
19065 ? 00:00:00 lyx <defunct>
19069 ? 00:00:00 lyx <defunct>

[levon]

are you using images ? how long do these zombies last ?

Not critical ...

[Mathieu.Dacremont@…]

the number of zombies is growing while i use lyx. they last until i quit the
program.

there is no image in my document.

[levon]

do you use the spellchecker ? If so, which versions ? Can you work out
what action is causing these processes to get created ?

[Mathieu.Dacremont@…]

I don't need to use the spellchecker to create zombies. Just changing the text
without saving the changes is enough to see new zombies. Can you replicate this
bug ?

[levon]

No, not at all. Seeing as simple text editing does not create any
new processes, it is illogical that there could be zombies :)

Can you provide an exact set of steps starting with launching LyX
that causes a zombie to appear ?

[Mathieu.Dacremont@…]

Here are the simple steps i follow to get zombies :

1) launch lyx
2) open a document of about 10000 words with sections and subsections
3) modify you text several times

I reproduce the bug on my laptop, still using RH 7.3, but the lyx rpm package
instead of the lyx source, and xforms rpm 0.89 instead of xforms source 0.88.
After 5 hours work, i had 24 zombies. It is worse than Resident Evil :-)

What tool can i use to gather more info about the generation of the defunct
processes ?

[Mathieu.Dacremont@…]

A lyx document i used to produce zombies

[levon]

This is not detailed enough to be able to reproduce. Please provide a (small !)
example document and detail exactly what you did to make the first zombie
appear.

If you are not using any of :

math-extern
external inset
spellchecker
graphics
view (dvi, export latex etc.)
chktex
version control

Then I do not see any circumstances where we create any other processes.

You can use gdb to find where the first process is getting forked. Do the
following :

gdb ./lyx
file ./lyx
break fork
run

Now create the zombie you are seeing, and lyx should freeze, you should now
be able to type "bt" into gdb and give us the backtrace.

[Mathieu.Dacremont@…]

After working 5 minutes on the document (see attachment), doing nothing other
then changing the text, i got this backtrace :

Breakpoint 1, 0x420b4b60 in fork () from /lib/i686/libc.so.6
(gdb) bt
#0 0x420b4b60 in fork () from /lib/i686/libc.so.6
#1 0x080e84b1 in AutoSave ()
#2 0x0808b29b in LyXView::AutoSave ()
#3 0x0808b9d2 in SigC::ObjectSlot0_<void, LyXView>::callback ()
#4 0x080547c7 in SigC::Signal0<void, SigC::Marshal<void> >::emit ()
#5 0x081f3d0b in Timeout::emit ()
#6 0x400998e6 in fl_handle_timeouts () from /usr/X11R6/lib/libforms.so.0.89
#7 0x40057f77 in fl_set_idle_delta () from /usr/X11R6/lib/libforms.so.0.89
#8 0x40056c3c in fl_last_event () from /usr/X11R6/lib/libforms.so.0.89
#9 0x40057649 in fl_treat_interaction_events ()

from /usr/X11R6/lib/libforms.so.0.89

#10 0x40057684 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#11 0x0826d239 in GUIRunTime::runTime ()
#12 0x080ea804 in LyXGUI::runTime ()
#13 0x080eaf2f in LyX::LyX ()
#14 0x081244c1 in main ()
#15 0x42017499 in libc_start_main () from /lib/i686/libc.so.6

Hope it will help.

[levon]

OUCH. Yes, this is totally valid. JMarc, Lars, how long have we been dumping
autosave processes everywhere like this ? Have you a 1.1.6 tree around ?

Quite a big embarrassing error

(thanks for the persistence Mathieu)

[levon]

Ugh, mine. Angus, how can we use forkedcontr to fix this ?

[leeming]

As I understand it, a zombie process is one that never terminates?That being the case, Forkedcall can't help you at all at the moment because it emits a signal only on termination of the forked process. However, Forkedcall does have a kill() method. So maybe you could invoke this after (say) 1 minute?Perhaps the real question to ask is why is the zombie not terminating?

[levon]

No, a zombie is when a process it terminated, but its parent has
not yet wait()ed for it. We aren't waiting for the autosave children
at all, hence they will stack up as zombies. The simple (super ugly)
solution is to make the reapSpellchecker wait4() instead of waitpid()
but I don't know how that interacts with forkedcontr.

What we want is a way to spawn the autosave and let the controller
worry about doing the wait() for it.

[levon]

Ugh, I haven't time to work on this, but this is quite serious...

[levon]

Punting - sorry, don't have time for this right now. Angus, can we
prevail upon you ?

[levon]

Resetting target milestone from 1.2.2

[lasgouttes]

Isn't this bug fixed in trunk? I we assume there will not be a 1.2.3 (likely),
then it is fixed.

[levon]

ok, sure.

[levon]

mass verify. grep -v ApplesWin