[elinks-dev] Crash when download ends

Kalle Olavi Niemitalo kon at iki.fi
Sun Sep 28 16:33:25 PDT 2008


Kalle Olavi Niemitalo <kon at iki.fi> writes:

> I guess we should make destroy_terminal() search for download.term
> pointers to that terminal, and reset them to NULL.
>
> struct download is used in these structures:

I wasn't thinking straight.  The pointer is file_download.term,
not download.term.  So it does not matter if struct download is
used in other places.

destroy_session() calls destroy_downloads(), which detaches file
downloads from the session that is being destroyed and tries to
attach them to some other session on the same terminal.  Possibly
we could make destroy_session() also set file_download.term =
NULL if no other session remains on the terminal.  Then,
destroy_terminal() might not have to explicitly detach file
downloads from the terminal, because it already destroys all tab
windows and their sessions on the terminal.

However, that won't work if it is possible to keep ELinks running
on a terminal that does not have any tab windows in it, and even
add file downloads to that terminal, e.g. by selecting them from
the download manager and telling ELinks to report on that
terminal when they complete.  Perhaps it is not possible now but
I don't want to leave such a trap in the source code.  So, I
think it would be better to have destroy_terminal() detach file
downloads from the terminal, rather than rely on destroy_session().

I don't understand why the file_download.ses pointer exists at all.
It seems to be used only for check_questions_queue(file_download->ses)
in abort_download().  But why does check_questions_queue() even take
a session parameter; shouldn't the terminal be used instead?
Of the functions given to add_questions_entry(), only do_auth_dialog()
and http_error_document() really use the session parameter rather than
just the terminal.  They seem to assume that the session is the
one where the authentication is needed or the HTTP error occurred,
but as far as I can tell, these assumptions do not always hold.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/elinks-dev/attachments/20080929/03c55104/attachment.sig>


More information about the elinks-dev mailing list