[Texmacs-dev] Re: Debugging memory management in TeXmacs

[Lionel Elie Mamane]

On Sun, Oct 22, 2006 at 10:53:43PM +0200, Joris van der Hoeven wrote:
> On Fri, Oct 20, 2006 at 11:45:27AM +0200, Lionel Elie Mamane wrote:

>>>> If found a reproducible way to crash TeXmacs, (...) The error is
>>>> that TeXmacs call free() on a pointer that was not returned by
>>>> malloc() (...)

>>> (...) I get a real backtrace now.

> Anyway, the error seems to be in the C++ code.

> It could be that the error is indeed due to TeXmacs, especially
> because it is in the recently added linking stuff, but it is very
> hard for me to debug this type of errors (if they don't come from my
> own code).

> Indeed, if you use some Guile code yourself in your plug-in and
> especially the tree modification routines, it may be that you did
> something wrong there.  Before I take a closer look, I would like to
> make sure that you are just using the TeXmacs protocol and nothing
> else.

I'm not sure I completely understand the question, but:

 - I don't (yet?) use the "Scheme sockets" that Henri pointed me
   towards.

 - I use the "TeXmacs exec()'s a program with stdin/out/err set to
   pipes and communicates with it over these" model of plug-in. I do
   use a custom serializer (that calls verbatim-serialize
   internally). I use the TeXmacs protocol, meaning that once the
   request from the TeXmacs side to the plugin process side is sent
   (that request is encoded in a plug-in specific way, by means of
   aforementioned custom serializer), the answer is a '\02' and '\05'
   delimited block, with other such blocks nested in (possibly 2 or 3
   layers deep); I use "scheme:" and "command:" blocks, as well as the
   "prompt#" channel.

Does this answer your question?

Furthermore, I do use tree manipulation routines, such as tree-set,
tree-set!, tree-remove, ...

> In that case, it could be a good idea to run with --debug-io and see
> at which point things go wrong.

That information may have been lost in noise in the deluge of emails I
sent, so I repeat (and extend) it here: The problem happens before any
IO (communication with the plug-in process) happens for this
particular request (obviously, IO happened to serve previous
requests. The problem happens at the time the user types "enter" (the
session not being in multiline mode, hence this calls the evaluation
of the command in that input field) in two specific input fields of a
specific Coq session in a specific order. The first evaluation goes
well, and then the second evaluation gives the error, but there it
happens before my Scheme code kicks in (before my custom serializer is
called) and hence before any communication happens; it happens when
executing the tmg_process_input C++ function, hence the process-input
Scheme function. I think that process-input itself is called from
kbd-return in session-edit.scm. It happens at the time that
tmg_process_input calls (indirectly, a few frames down in the
backtrace) edit_modify_rep::assign to replace the (output (...)) node
in the document following directly the (input (...) (...)) node the
cursor was in when the user typed enter with the following: (output
(document ())). (I uncommented the first line of "assign" in
src/Classes/Abstract/observer.cpp, and here is
what it says:

 Assign output (document (concat (unfolded (, document (subgoal 1 is:,   ,   l' 
: list A,   ============================,    rev l' = rev l' ++ nil)), , ))) := 
output (document ())


It is indeed not entirely ruled out that my Scheme code has led to the
corruption of an internal TeXmacs structure that leads to this error
later, but at this point my analysis leads me to conclude my Scheme
code is not in the call stack at the time the error happens.

-- 
Lionel