[prev in list] [next in list] [prev in thread] [next in thread] 

List:       elinks-dev
Subject:    Re: [elinks-dev] dangling pointer crash in write_to_festival
From:       Kalle Olavi Niemitalo <kon () iki ! fi>
Date:       2007-03-07 10:32:05
Message-ID: 873b4hl4yi.fsf () Astalo ! kon ! iki ! fi
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

Content-Transfer-Encoding: quoted-printable

Witold Filipczyk <witekfl@poczta.onet.pl> writes:

> I reset festival.doc_view in really_close_tab. Is it acceptable?

I think that is too far from the code that frees the struct
document_view.  Even if really_close_tab currently were the only
way to free a struct document_view, that could change in the
future, and the person changing it would probably not remember to
add a call to stop_festival.

In fact, really_close_tab is already not the only way: if I
navigate away from a frameset page, then a struct document_view
that festival.c is using can be freed, even though
really_close_tab is not called.

It seems many places that free struct document_view call
detach_formatted first, so you could perhaps call stop_festival
From=20there instead.  However, if we're going to assume that
detach_formatted is always called before struct document_view is
freed, then this should first be carefully checked, and then
documented in a comment near the definition of struct
document_view.

> When a link is followed and the previous document was read out,
> the new document is read out from the line number of the
> previous document.  How to handle this?

detach_formatted seems to be called in that situation too, so if
it's OK to stop the speech, that should fix it.

By the way, the "default" in "Default speech system" is not
right, because ELinks does not even try speech systems other than
the one selected here.

[Attachment #5 (application/pgp-signature)]

_______________________________________________
elinks-dev mailing list
elinks-dev@linuxfromscratch.org
http://linuxfromscratch.org/mailman/listinfo/elinks-dev


[prev in list] [next in list] [prev in thread] [next in thread]