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 _______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
