#643 coredump if macro re-defines itself

open
nobody
Program (402)
5
2008-09-16
2008-09-16
Bert Wesarg
No

If you define a function, which loads a macro file, which re-defines the current function, nedit segfaults. Because it unconditionally calls ProgramFree() on the yet overridden symbol.

This bug is hardly triggered, but if you memset(0) the prog->code in the FreeProgram() function before XtFree(), it hits you right away.

To reproduce:

===autoload.nm===
define bug {
load_macro_file($file_path $file_name)

t_print("yuhuu\n")
}
===autoload.nm===

===bug.menu===
nedit.macroCommands: \ bug me@NEdit Macro:F2::: {\n\ bug()\n\ }\n
===bug.menu===

than run:

NEDIT_HOME=$PWD ./source/nedit -import bug.menu autoload.nm

and hit F2

The only solution for now is, to remove the call to FreeProgram(). Unfortunately, this is in contradiction to bug #2078867 "memory leak in readCheckMacroString() ".

Discussion

  • Tony Balinski

    Tony Balinski - 2008-09-16

    You can get much the same effect by reloading a macro file, or redefining a macro menu item whose code is in charge of a dialog box currently being displayed. I've been bitten by this often enough, hitting Apply on the menu entry dialog while that menu entry is already executing something.

     
  • Bert Wesarg

    Bert Wesarg - 2008-09-16

    Thanks for confirmation, and good to know that there are more places.

    Any ideas what we can do? A reference count for the Program comes to my mind plus my pseudo frame idea from the other bug.

     
  • Bert Wesarg

    Bert Wesarg - 2008-09-16

    As a immediate fix, I would propose to just disable the FreeProgram() call in case of re-definition of a macro symbol.

    File Added: disable-FreeProgram.patch.txt

     
  • Bert Wesarg

    Bert Wesarg - 2008-09-16

    immediate fix

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks