coredump on options parsing

coredump on options parsing

[Clint Adams]

Is seems that any calls to trashzle() from within
zerr() or zerrnam() when called from init.c
result in a segmentation fault.

This occurs in zsh 3.1.x on Linux and Solaris,
but works just fine in 3.0.5.

Any ideas why?

Re: coredump on options parsing

[Bart Schaefer]

On Feb 6, 11:50pm, Clint Adams wrote:
} Subject: coredump on options parsing
}
} Is seems that any calls to trashzle() from within
} zerr() or zerrnam() when called from init.c
} result in a segmentation fault.

Some instructions on how to reproduce this might help.  "zerr() from init.c"
isn't very useful.

} This occurs in zsh 3.1.x

Including 3.1.5-pws-7, announced here on zsh-workers recently?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: coredump on options parsing

[Clint Adams]

> Some instructions on how to reproduce this might help.  "zerr() from init.c"
> isn't very useful.

Sure.  This occurs when you do zsh -c or -o without following arguments,
or attempt to run zsh <filename> on a nonexistent file.

> Including 3.1.5-pws-7, announced here on zsh-workers recently?

Yes.

PATCH: 3.1.5: Re: coredump on options parsing

[Bart Schaefer]

On Feb 7, 12:23am, Clint Adams wrote:
} Subject: Re: coredump on options parsing
}
} > Some instructions on how to reproduce this might help.
} 
} Sure.  This occurs when you do zsh -c or -o without following arguments,
} or attempt to run zsh <filename> on a nonexistent file.

Aha.  The problem is that ZLE is in a module, and the module hasn't yet
been initialized at that point.  So the function pointer for trashzle()
does not actually point anywhere yet.  (This is only true when NOT using
dynamic modules, which is probably why nobody noticed.)

The following should fix it.

Index: Src/init.c
===================================================================
--- init.c	1999/02/05 17:53:25	1.13
+++ init.c	1999/02/07 06:45:48
@@ -890,6 +890,20 @@
     mod.nam = NULL;
 }
 
+/**/
+void
+noop_function(void)
+{
+    /* do nothing */
+}
+
+/**/
+void
+noop_function_int(int nothing)
+{
+    /* do nothing */
+}
+
 /* ZLE entry point pointers.  They are defined here because the initial *
  * values depend on whether ZLE is linked in or not -- if it is, we     *
  * avoid wasting space with the fallback functions.  No other source    *
@@ -898,7 +912,7 @@
 #ifdef LINKED_XMOD_zle
 
 /**/
-ZleVoidFn trashzleptr;
+ZleVoidFn trashzleptr = noop_function;
 /**/
 ZleVoidFn gotwordptr;
 /**/
@@ -919,20 +933,6 @@
 # else /* !UNLINKED_XMOD_zle */
 ZleReadFn zlereadptr = fallback_zleread;
 # endif /* !UNLINKED_XMOD_zle */
-
-/**/
-void
-noop_function(void)
-{
-    /* do nothing */
-}
-
-/**/
-void
-noop_function_int(int nothing)
-{
-    /* do nothing */
-}
 
 /**/
 # ifdef UNLINKED_XMOD_zle

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com