functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

I updated today from CVS sources and built. I tried a little test and
alas, I'm sorry to report that I can't use this.

I've attached the little test program called linebug.sh. It doesn't do
any "source"'ing.  rocky-patch.out contains the output given with the
patch I submitted. functrace.out contains output using $functrace and
funcsourcetrace.out contains output using $funcsourcetrace.out.

Right now I can't see how to patch together the output from functrace
and funcsourcetrace. But it really doesn't matter because it shouldn't
be that convoluted either. What we want is an array that contains the
source file name  and absolute line number of the place where we were
called from. If the caller has a caller, then another array entry for
the source file and line number of that location, and so on. This is
the way it works in virtually every other programming language I can
think of. Perl, Python, Ruby, Java, C, C++, bash, ksh, LISP, to name
some that come to mind.

Right now functrace (whose output is shown in functrace.out), seems to
come the closest were it not for this function information getting put
there inside functions instead, and which is sort of duplicated in
funcstack. I am not fussy about what name you want to give this,
whether you want to have several parallel arrays for functions, file
names, line numbers and so on, or fewer with each string encoding more
than one bit of information. However the the filenames and line
numbers have to be there, and match the information as shown in
rocky-patch.out for the run in linebug.sh.

Thanks.


On Tue, Aug 12, 2008 at 4:27 PM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On Tue, 12 Aug 2008 15:58:03 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
>> > I'm not sure what to put in $funcsourcetrace since there is no separate
>> > point of definition from that of the caller in this case.
>>
>> How about "source" or ".". Down the line one may want to record the
>> number of parameters passed, and here I note that zsh allows passing
>> parameters in a source command.
>
> OK, I've committed it so that the funcsourcetrace element shows up as
> "source:0".
>
> I had a look at providing the text for debug traps but it wasn't as
> trivial as I'd hoped so that may have to wait.
>
> --
> Peter Stephenson <p.w.stephenson@ntlworld.com>
> Web page now at http://homepage.ntlworld.com/p.w.stephenson/
>
>

[-- Attachment #2: linebug.sh --]
[-- Type: application/x-sh, Size: 231 bytes --]

[-- Attachment #3: rocky-patch.out --]
[-- Type: application/octet-stream, Size: 236 bytes --]

$ /usr/local/bin/zsh linebug.sh

linebug.sh:9
====
linebug.sh:13
====
linebug.sh:16
====
linebug.sh:10
linebug.sh:16
====
calling bar 10
linebug.sh:11
linebug.sh:16
====
linebug.sh:14
linebug.sh:11
linebug.sh:16
====
linebug.sh:17
====

[-- Attachment #4: functrace.out --]
[-- Type: application/octet-stream, Size: 277 bytes --]

$ /usr/local/bin/zsh ./linebug.sh

./linebug.sh:9
====
./linebug.sh:13
====
./linebug.sh:16
====
foo:1
./linebug.sh:16
====
calling bar 10
foo:2
./linebug.sh:16
====
bar:1
foo:2
./linebug.sh:16
====
./linebug.sh:17
====
 7:17PM rocky@dr-ferdinand /src/git/zshdb/bug [3 z] 0
$ 

[-- Attachment #5: funcsourcetrace.out --]
[-- Type: application/octet-stream, Size: 251 bytes --]

$ /usr/local/bin/zsh ./linebug.sh

./linebug.sh:1
====
./linebug.sh:1
====
./linebug.sh:1
====
./linebug.sh:1
./linebug.sh:9
====
calling bar 10
./linebug.sh:1
./linebug.sh:9
====
./linebug.sh:1
./linebug.sh:13
./linebug.sh:9
====
./linebug.sh:1
====

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Peter Stephenson]

On Tue, 12 Aug 2008 20:00:40 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
> I've attached the little test program called linebug.sh. It doesn't do
> any "source"'ing.  rocky-patch.out contains the output given with the
> patch I submitted. functrace.out contains output using $functrace and
> funcsourcetrace.out contains output using $funcsourcetrace.out.

As I said, deciding what's in the calling context and what's in the
current context is difficult.  We've got something that consistently
tracks only the calling context; it seems what we need to end up with is
a mixture with the next level up.

Let's analyse the differences in one of the key bits, in a function call;
here they are in parallel:

functrace         funcsourcetrace   rocky                where we are

foo:1             ./linebug.sh:1    linebug.sh:10        print_stack
./linebug.sh:16   ./linebug.sh:9    linebug.sh:16        foo

In the first line,

- foo:1 means "we (print_stack) were called from the first line in the
  function foo"
- ./linebug.sh:1 means "the definition of print_stack is at line 1 in
  linebug.sh"
- linebug.sh:10 means "the caller of print_stack is at line 10
  in linebug.sh, regardless of where the line in the function is".

In the second line,

- ./linebug.sh:16 means "our own caller (foo) was called here"; this
  is a script, not a function, so it's a filename, not a function name.
- ./linebug.sh:9 means "foo was defined starting here"
- ./linebug.sh:16 means "our own caller was run at this line in this file"

So the number Rocky wants for the function context is actually the first
line from functrace plus the second line from funcsourcetrace (which is
the point at which line number 0 of foo occurs).  So to do this
consistently for functions, it looks like we need an array that keeps
the file from the next level up in funcsourcetrace (the function might
be defined in a different file, and that's what we need to get the right
line number) and adds that line number to the line number in the
immediately calling context.

This should be doable (without too much additional help, anyway)
entirely within a new function (corresponding to a new array) in the
parameter module.  The major decision is whether the immediate caller is
a function, in which case do the addition as above, or not, in which
case just report the current functrace output.  The functrace output
should be fine for source'd files, too.

I'll have a look at this when I get back (unless I get bored on holiday).

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Peter Stephenson]

On Wed, 13 Aug 2008 20:42:12 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> I'll have a look at this when I get back (unless I get bored on holiday).

I lied.

I think this one does specifically what you want, and if it doesn't, we
should now have enough information to tweak it.  No test yet, that
really *will* have to wait, but I've checked with autoloaded functions
and because I made funcsourcetrace consistent the last time round they
seem to work OK.  Running your script with $funcfiletrace gave the files
and line numbers you wanted.

I've left $funcsourcetrace, since we need to have the information for it
anyway, but I'm assuming it's going to be of fairly specialist interest,
so I've documented it as such.

Index: Doc/Zsh/mod_parameter.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_parameter.yo,v
retrieving revision 1.10
diff -u -r1.10 mod_parameter.yo
--- Doc/Zsh/mod_parameter.yo	12 Aug 2008 20:25:14 -0000	1.10
+++ Doc/Zsh/mod_parameter.yo	13 Aug 2008 20:33:16 -0000
@@ -164,6 +164,16 @@
 This associative array maps user names to the pathnames of their home
 directories.
 )
+vindex(funcfiletrace)
+item(tt(funcfiletrace))(
+This array contains the absolute line numbers and corresponding file
+names for the point where the current function or sourced file was
+called.  The array is of the same length as tt(funcsourcetrace) and
+tt(functrace), but differs from tt(funcsourcetrace) in that the line and
+file are the point of call, not the point of definition, and differs
+from tt(functrace) in that all values are absolute line numbers in
+files, rather than relative to the start of a function, if any.
+)
 vindex(funcsourcetrace)
 item(tt(funcsourcetrace))(
 This array contains the file names and line numbers of the 
@@ -176,6 +186,9 @@
 For files that have been executed by the tt(source) or tt(.) builtins
 (in which case there is no separate definition) the trace information is
 shown as tt(source:0).
+
+Most users will be interested in the information in the
+tt(funcfiletrace) array instead.
 )
 vindex(funcstack)
 item(tt(funcstack))(
Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.139
diff -u -r1.139 exec.c
--- Src/exec.c	11 Aug 2008 19:22:54 -0000	1.139
+++ Src/exec.c	13 Aug 2008 20:33:19 -0000
@@ -4258,6 +4258,7 @@
     fstack.caller = dupstring(oargv0 ? oargv0 : argzero);
     fstack.lineno = lineno;
     fstack.prev = funcstack;
+    fstack.sourced = 0;
     funcstack = &fstack;
 
     if ((shf = (Shfunc) shfunctab->getnode(shfunctab, name))) {
Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.93
diff -u -r1.93 init.c
--- Src/init.c	12 Aug 2008 20:25:14 -0000	1.93
+++ Src/init.c	13 Aug 2008 20:33:19 -0000
@@ -1109,6 +1109,7 @@
        fstack.lineno = oldlineno;
        fstack.filename = fstack.name;
        fstack.prev = funcstack;
+       fstack.sourced = 1;
        funcstack = &fstack;
     }
     
Index: Src/zsh.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v
retrieving revision 1.141
diff -u -r1.141 zsh.h
--- Src/zsh.h	11 Aug 2008 19:22:54 -0000	1.141
+++ Src/zsh.h	13 Aug 2008 20:33:20 -0000
@@ -1080,11 +1080,12 @@
 
 struct funcstack {
     Funcstack prev;		/* previous in stack */
-    char *name;			/* name of function called */
+    char *name;			/* name of function/sourced file called */
     char *filename;		/* file function resides in */
     char *caller;		/* name of caller */
     zlong flineno;		/* line number in file */
     zlong lineno;		/* line offset from beginning of function */
+    int sourced;		/* type of entry is a sourced file */
 };
 
 /* node in list of function call wrappers */
Index: Src/Modules/parameter.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/parameter.c,v
retrieving revision 1.46
diff -u -r1.46 parameter.c
--- Src/Modules/parameter.c	11 Aug 2008 19:22:54 -0000	1.46
+++ Src/Modules/parameter.c	13 Aug 2008 20:33:21 -0000
@@ -566,6 +566,55 @@
     return ret;
 }
 
+/* Functions for the funcfiletrace special parameter. */
+
+/**/
+static char **
+funcfiletracegetfn(UNUSED(Param pm))
+{
+    Funcstack f;
+    int num;
+    char **ret, **p;
+
+    for (f = funcstack, num = 0; f; f = f->prev, num++);
+
+    ret = (char **) zhalloc((num + 1) * sizeof(char *));
+
+    for (f = funcstack, p = ret; f; f = f->prev, p++) {
+	char *colonpair, *fname;
+
+	if (!f->prev || f->prev->sourced) {
+	    /*
+	     * Calling context is a file---either the parent
+	     * script or interactive shell, or a sourced
+	     * script.  Just print the file information for the caller
+	     * (same as $functrace)
+	     */
+	    colonpair = zhalloc(strlen(f->caller) +
+				(f->lineno > 9999 ? 24 : 6));
+	    sprintf(colonpair, "%s:%ld", f->caller, (long)f->lineno);
+	} else {
+	    /*
+	     * Calling context is a function; we need to find the line number
+	     * in the file where that function was defined.  For this we need
+	     * the $funcsourcetrace information for the context above,
+	     * together with the $functrace line number for the current
+	     * context.
+	     */
+	    long flineno = (long)(f->prev->flineno + f->lineno);
+	    fname = f->prev->filename ? f->prev->filename : "";
+
+	    colonpair = zhalloc(strlen(fname) + (flineno > 9999 ? 24 : 6));
+	    sprintf(colonpair, "%s:%ld", fname, flineno);
+	}
+
+	*p = colonpair;
+    }
+    *p = NULL;
+
+    return ret;
+}
+
 /* Functions for the builtins special parameter. */
 
 /**/
@@ -1803,6 +1852,8 @@
 { functracegetfn, arrsetfn, stdunsetfn };
 static const struct gsu_array funcsourcetrace_gsu =
 { funcsourcetracegetfn, arrsetfn, stdunsetfn };
+static const struct gsu_array funcfiletrace_gsu =
+{ funcfiletracegetfn, arrsetfn, stdunsetfn };
 static const struct gsu_array reswords_gsu =
 { reswordsgetfn, arrsetfn, stdunsetfn };
 static const struct gsu_array disreswords_gsu =
@@ -1831,6 +1882,8 @@
 	    &disreswords_gsu, NULL, NULL),
     SPECIALPMDEF("dis_saliases", 0,
 	    &pmdissaliases_gsu, getpmdissalias, scanpmdissaliases),
+    SPECIALPMDEF("funcfiletrace", PM_ARRAY|PM_READONLY,
+	    &funcfiletrace_gsu, NULL, NULL),
     SPECIALPMDEF("funcsourcetrace", PM_ARRAY|PM_READONLY,
 	    &funcsourcetrace_gsu, NULL, NULL),
     SPECIALPMDEF("funcstack", PM_ARRAY|PM_READONLY,
Index: Src/Modules/parameter.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/parameter.mdd,v
retrieving revision 1.6
diff -u -r1.6 parameter.mdd
--- Src/Modules/parameter.mdd	11 Aug 2008 19:22:54 -0000	1.6
+++ Src/Modules/parameter.mdd	13 Aug 2008 20:33:21 -0000
@@ -2,6 +2,6 @@
 link=either
 load=yes
 
-autofeatures="p:parameters p:commands p:functions p:dis_functions p:funcsourcetrace p:funcstack p:functrace p:builtins p:dis_builtins p:reswords p:dis_reswords p:options p:modules p:dirstack p:history p:historywords p:jobtexts p:jobdirs p:jobstates p:nameddirs p:userdirs p:aliases p:dis_aliases p:galiases p:dis_galiases p:saliases p:dis_saliases"
+autofeatures="p:parameters p:commands p:functions p:dis_functions p:funcfiletrace p:funcsourcetrace p:funcstack p:functrace p:builtins p:dis_builtins p:reswords p:dis_reswords p:options p:modules p:dirstack p:history p:historywords p:jobtexts p:jobdirs p:jobstates p:nameddirs p:userdirs p:aliases p:dis_aliases p:galiases p:dis_galiases p:saliases p:dis_saliases"
 
 objects="parameter.o"

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Peter Stephenson]

On Wed, 13 Aug 2008 21:43:18 +0100
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> I think this one does specifically what you want, and if it doesn't, we
> should now have enough information to tweak it.

Committed, since it's certainly going the right way.  I'm now likely to be offline for
a week and a bit.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Rocky Bernstein]

Thanks! I've updated the zshdb sources on github.  For the first time
we have a zshdb that works with the current CVS sources without
additional patching. This is definitely progress!

I tried the statement skip code using setopt errorexit, but what seems
to be happening is that the rest of the program runs and the trap
DEBUG is killed. I will investigate sometime after my holiday.

Enjoy yours!

On Wed, Aug 13, 2008 at 5:05 PM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On Wed, 13 Aug 2008 21:43:18 +0100
> Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> I think this one does specifically what you want, and if it doesn't, we
>> should now have enough information to tweak it.
>
> Committed, since it's certainly going the right way.  I'm now likely to be offline for
> a week and a bit.
>
> --
> Peter Stephenson <p.w.stephenson@ntlworld.com>
> Web page now at http://homepage.ntlworld.com/p.w.stephenson/
>

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Mikael Magnusson]

2008/8/13 Peter Stephenson <p.w.stephenson@ntlworld.com>:
> On Wed, 13 Aug 2008 21:43:18 +0100
> Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> I think this one does specifically what you want, and if it doesn't, we
>> should now have enough information to tweak it.
>
> Committed, since it's certainly going the right way.  I'm now likely to be offline for
> a week and a bit.

The current cvs zsh crashes for me on any tabcompletion now iff i've
done a zcompile on the functions dir in /usr/local/share/zsh/blabla.
The first commit with the crash is "25247 with further modifications:
add $funcsourcetrace":

% cd<tab>
Program received signal SIGSEGV, Segmentation fault.
0x41b6624b in strlen () from /lib/libc.so.6
(gdb) bt
#0  0x41b6624b in strlen () from /lib/libc.so.6
#1  0x080bfb10 in dupstring (s=0x3cff9c3 <Address 0x3cff9c3 out of
bounds>) at string.c:39
#2  0x08073673 in execautofn (state=0xaf92bf1c, do_exec=0) at exec.c:4075
#3  0x08071045 in execcmd (state=0xaf92bf1c, input=0, output=0,
how=18, last1=2) at exec.c:2979
#4  0x0806cfe2 in execpline2 (state=0xaf92bf1c, pcode=3, how=18,
input=0, output=0, last1=0)
    at exec.c:1541
#5  0x0806c378 in execpline (state=0xaf92bf1c, slcode=3074, how=18,
last1=0) at exec.c:1327
#6  0x0806bbb9 in execlist (state=0xaf92bf1c, dont_change_job=1,
exiting=0) at exec.c:1125
#7  0x0806b725 in execode (p=0x82cd5c8, dont_change_job=1, exiting=0)
at exec.c:965
#8  0x08074063 in runshfunc (prog=0x82cd5c8, wrap=0x0, name=0xa7ae7710
"_normal") at exec.c:4382
#9  0xa7b219fc in comp_wrapper (prog=0x82cd5c8, w=0x0, name=0xa7ae7710
"_normal")
    at complete.c:1449
#10 0x08073ff2 in runshfunc (prog=0x82cd5c8, wrap=0xa7b3c720,
name=0xa7ae7710 "_normal")
    at exec.c:4370
#11 0x08073dd6 in doshfunc (name=0x82cd608 "_normal", prog=0x82cd5c8,
doshargs=0xa7ae76d0,
    flags=270848, noreturnval=0) at exec.c:4291
#12 0x080735c5 in execshfunc (shf=0x82cd5a8, args=0xa7ae76d0) at exec.c:4044
#13 0x0807123c in execcmd (state=0xaf92ce2c, input=0, output=0, how=2,
last1=2) at exec.c:3027
#14 0x0806cfe2 in execpline2 (state=0xaf92ce2c, pcode=7555, how=2,
input=0, output=0, last1=0)
    at exec.c:1541
#15 0x0806c378 in execpline (state=0xaf92ce2c, slcode=4130, how=2,
last1=0) at exec.c:1327
#16 0x0806bc05 in execlist (state=0xaf92ce2c, dont_change_job=1,
exiting=0) at exec.c:1132
#17 0x08093dea in execif (state=0xaf92ce2c, do_exec=0) at loop.c:515
#18 0x08071045 in execcmd (state=0xaf92ce2c, input=0, output=0, how=2,
last1=2) at exec.c:2979
#19 0x0806cfe2 in execpline2 (state=0xaf92ce2c, pcode=7427, how=2,
input=0, output=0, last1=0)
    at exec.c:1541
#20 0x0806c378 in execpline (state=0xaf92ce2c, slcode=114690, how=2,
last1=0) at exec.c:1327
#21 0x0806bbb9 in execlist (state=0xaf92ce2c, dont_change_job=1,
exiting=0) at exec.c:1125
#22 0x0806b725 in execode (p=0x82cd790, dont_change_job=1, exiting=0)
at exec.c:965
---Type <return> to continue, or q <return> to quit---
#23 0x080736c1 in execautofn (state=0xaf92d48c, do_exec=0) at exec.c:4080
#24 0x08071045 in execcmd (state=0xaf92d48c, input=0, output=0,
how=18, last1=2) at exec.c:2979
#25 0x0806cfe2 in execpline2 (state=0xaf92d48c, pcode=3, how=18,
input=0, output=0, last1=0)
    at exec.c:1541
#26 0x0806c378 in execpline (state=0xaf92d48c, slcode=3074, how=18,
last1=0) at exec.c:1327
#27 0x0806bbb9 in execlist (state=0xaf92d48c, dont_change_job=1,
exiting=0) at exec.c:1125
#28 0x0806b725 in execode (p=0x82c59e8, dont_change_job=1, exiting=0)
at exec.c:965
#29 0x08074063 in runshfunc (prog=0x82c59e8, wrap=0x0, name=0xa7ae71f0
"_complete")
    at exec.c:4382
#30 0xa7b219fc in comp_wrapper (prog=0x82c59e8, w=0x0, name=0xa7ae71f0
"_complete")
    at complete.c:1449
#31 0x08073ff2 in runshfunc (prog=0x82c59e8, wrap=0xa7b3c720,
name=0xa7ae71f0 "_complete")
    at exec.c:4370
#32 0x08073dd6 in doshfunc (name=0x82c5a28 "_complete",
prog=0x82c59e8, doshargs=0xa7ae71b0,
    flags=270848, noreturnval=0) at exec.c:4291
#33 0x080735c5 in execshfunc (shf=0x82c59c8, args=0xa7ae71b0) at exec.c:4044
#34 0x0807123c in execcmd (state=0xaf92f0bc, input=0, output=0,
how=18, last1=2) at exec.c:3027
#35 0x0806cfe2 in execpline2 (state=0xaf92f0bc, pcode=10371, how=18,
input=0, output=0, last1=0)
    at exec.c:1541
#36 0x0806c378 in execpline (state=0xaf92f0bc, slcode=3074, how=18,
last1=0) at exec.c:1327
#37 0x0806bbb9 in execlist (state=0xaf92f0bc, dont_change_job=1,
exiting=0) at exec.c:1125
#38 0x08093d45 in execif (state=0xaf92f0bc, do_exec=0) at loop.c:500
#39 0x08071045 in execcmd (state=0xaf92f0bc, input=0, output=0, how=2,
last1=2) at exec.c:2979
#40 0x0806cfe2 in execpline2 (state=0xaf92f0bc, pcode=10051, how=2,
input=0, output=0, last1=0)
    at exec.c:1541
#41 0x0806c378 in execpline (state=0xaf92f0bc, slcode=48130, how=2,
last1=0) at exec.c:1327
#42 0x0806bbb9 in execlist (state=0xaf92f0bc, dont_change_job=1,
exiting=0) at exec.c:1125
#43 0x0809300c in execfor (state=0xaf92f0bc, do_exec=0) at loop.c:159
#44 0x08071045 in execcmd (state=0xaf92f0bc, input=0, output=0, how=2,
last1=2) at exec.c:2979
---Type <return> to continue, or q <return> to quit---
#45 0x0806cfe2 in execpline2 (state=0xaf92f0bc, pcode=9539, how=2,
input=0, output=0, last1=0)
    at exec.c:1541
#46 0x0806c378 in execpline (state=0xaf92f0bc, slcode=90114, how=2,
last1=0) at exec.c:1327
#47 0x0806bbb9 in execlist (state=0xaf92f0bc, dont_change_job=1,
exiting=0) at exec.c:1125
#48 0x0809300c in execfor (state=0xaf92f0bc, do_exec=0) at loop.c:159
#49 0x08071045 in execcmd (state=0xaf92f0bc, input=0, output=0, how=2,
last1=2) at exec.c:2979
#50 0x0806cfe2 in execpline2 (state=0xaf92f0bc, pcode=8067, how=2,
input=0, output=0, last1=0)
    at exec.c:1541
#51 0x0806c378 in execpline (state=0xaf92f0bc, slcode=220162, how=2,
last1=0) at exec.c:1327
#52 0x0806bbb9 in execlist (state=0xaf92f0bc, dont_change_job=1,
exiting=0) at exec.c:1125
#53 0x0806b725 in execode (p=0x82e0e50, dont_change_job=1, exiting=0)
at exec.c:965
#54 0x080736c1 in execautofn (state=0xaf92f71c, do_exec=0) at exec.c:4080
#55 0x08071045 in execcmd (state=0xaf92f71c, input=0, output=0,
how=18, last1=2) at exec.c:2979
#56 0x0806cfe2 in execpline2 (state=0xaf92f71c, pcode=3, how=18,
input=0, output=0, last1=0)
    at exec.c:1541
#57 0x0806c378 in execpline (state=0xaf92f71c, slcode=3074, how=18,
last1=0) at exec.c:1327
#58 0x0806bbb9 in execlist (state=0xaf92f71c, dont_change_job=1,
exiting=0) at exec.c:1125
#59 0x0806b725 in execode (p=0x82cbf30, dont_change_job=1, exiting=0)
at exec.c:965
#60 0x08074063 in runshfunc (prog=0x82cbf30, wrap=0x0, name=0xa7ae5030
"_main_complete")
    at exec.c:4382
#61 0xa7b219fc in comp_wrapper (prog=0x82cbf30, w=0x0, name=0xa7ae5030
"_main_complete")
    at complete.c:1449
#62 0x08073ff2 in runshfunc (prog=0x82cbf30, wrap=0xa7b3c720,
name=0xa7ae5030 "_main_complete")
    at exec.c:4370
#63 0x08073dd6 in doshfunc (name=0x829bad8 "_main_complete",
prog=0x82cbf30, doshargs=0x0,
    flags=0, noreturnval=0) at exec.c:4291
#64 0xa7b242e1 in callcompfunc (s=0xa7c72758 "", fn=0x829bad8
"_main_complete") at compcore.c:817
#65 0xa7b24bb3 in makecomplist (s=0xa7c72758 "", incmd=0, lst=0) at
compcore.c:968
#66 0xa7b22942 in do_completion (dummy=0xa7b7a9d4, dat=0xaf92fb98) at
compcore.c:349
---Type <return> to continue, or q <return> to quit---
#67 0x0809ae60 in runhookdef (h=0xa7b7a9d4, d=0xaf92fb98) at module.c:996
#68 0xa7b6a9b7 in docompletion (s=0x82dff38 "", lst=0, incmd=0) at
zle_tricky.c:2135
#69 0xa7b66a37 in docomplete (lst=0) at zle_tricky.c:859
#70 0xa7b654b7 in expandorcomplete (args=0xa7b7ac9c) at zle_tricky.c:315
#71 0xa7b6505a in completecall (args=0xa7b7ac9c) at zle_tricky.c:208
#72 0xa7b54c82 in execzlefunc (func=0xa7b78cd0, args=0xa7b7ac9c,
set_bindk=0) at zle_main.c:1291
#73 0xa7b541b2 in zlecore () at zle_main.c:1043
#74 0xa7b548c3 in zleread (lp=0x80f4adc, rp=0x80f4a64, flags=7,
context=0) at zle_main.c:1205
#75 0xa7b56a51 in zle_main_entry (cmd=1, ap=0xaf930004 "") at zle_main.c:1834
#76 0x08087189 in zleentry (cmd=1) at init.c:1256
#77 0x08087a6a in inputline () at input.c:278
#78 0x080878d9 in ingetc () at input.c:214
#79 0x0807de0e in ihgetc () at hist.c:263
#80 0x0808fc03 in gettok () at lex.c:663
#81 0x0808f48e in yylex () at lex.c:350
#82 0x080abe21 in parse_event () at parse.c:451
#83 0x08084827 in loop (toplevel=1, justonce=0) at init.c:129
#84 0x0808750a in zsh_main (argc=1, argv=0xaf930264) at init.c:1407
#85 0x080551f6 in main (argc=Cannot access memory at address 0x3
) at ./main.c:93
(gdb) print shf->filename
No symbol "shf" in current context.
(gdb) frame 1
#1  0x080bfb10 in dupstring (s=0x3cff9c3 <Address 0x3cff9c3 out of
bounds>) at string.c:39
39	    t = (char *) zhalloc(strlen((char *)s) + 1);
(gdb) print s
$1 = 0x3cff9c3 <Address 0x3cff9c3 out of bounds>

-- 
Mikael Magnusson

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Peter Stephenson]

On Mon, 18 Aug 2008 13:13:39 +0200
"Mikael Magnusson" <mikachu@gmail.com> wrote:
> The current cvs zsh crashes for me on any tabcompletion now iff i've
> done a zcompile on the functions dir in /usr/local/share/zsh/blabla.

If it's only with zcompile'd functions, it could be it just needs a
version number update to deconfuse matters.  It's time I produced a dev
version with a new number.  (There are various things I still need to do
before a proper beta release, most notably the other half of the
completion match control conversion to wide characters.)  I'm around
until Monday, I'll try and fit it in.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Mikael Magnusson]

2008/8/21 Peter Stephenson <p.w.stephenson@ntlworld.com>:
> On Mon, 18 Aug 2008 13:13:39 +0200
> "Mikael Magnusson" <mikachu@gmail.com> wrote:
>> The current cvs zsh crashes for me on any tabcompletion now iff i've
>> done a zcompile on the functions dir in /usr/local/share/zsh/blabla.
>
> If it's only with zcompile'd functions, it could be it just needs a
> version number update to deconfuse matters.  It's time I produced a dev
> version with a new number.  (There are various things I still need to do
> before a proper beta release, most notably the other half of the
> completion match control conversion to wide characters.)  I'm around
> until Monday, I'll try and fit it in.

It happens with newly zcompiled .zwc files as well, ie
1) install cvs
2) zcompile + tab -> crash
3) rm .zwc + tab -> nocrash
4) zcompile + tab -> crash again

Actually... If I remember correctly, it didn't crash with the zwc from
before the commit, but it could be that it's just not loaded at all then.

-- 
Mikael Magnusson

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Peter Stephenson]

On Mon, 18 Aug 2008 13:13:39 +0200
"Mikael Magnusson" <mikachu@gmail.com> wrote:
> The current cvs zsh crashes for me on any tabcompletion now iff i've
> done a zcompile on the functions dir in /usr/local/share/zsh/blabla.
> The first commit with the crash is "25247 with further modifications:
> add $funcsourcetrace":
> 
> % cd<tab>
> Program received signal SIGSEGV, Segmentation fault.
> 0x41b6624b in strlen () from /lib/libc.so.6
> (gdb) bt
> #0  0x41b6624b in strlen () from /lib/libc.so.6
> #1  0x080bfb10 in dupstring (s=0x3cff9c3 <Address 0x3cff9c3 out of
> bounds>) at string.c:39
> #2  0x08073673 in execautofn (state=0xaf92bf1c, do_exec=0) at exec.c:4075

Looking at this part of the trace, I wonder if this is the problem?

We could do with some tests for zcompile.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.139
diff -u -r1.139 exec.c
--- Src/exec.c	11 Aug 2008 19:22:54 -0000	1.139
+++ Src/exec.c	22 Aug 2008 15:32:16 -0000
@@ -4405,8 +4405,11 @@
 	    sprintf(buf, "%s/%s", *pp, s);
 	else
 	    strcpy(buf, s);
-	if ((r = try_dump_file(*pp, s, buf, ksh)))
+	if ((r = try_dump_file(*pp, s, buf, ksh))) {
+	    if (fname)
+		*fname = ztrdup(buf);
 	    return r;
+	}
 	unmetafy(buf, NULL);
 	if (!access(buf, R_OK) && (fd = open(buf, O_RDONLY | O_NOCTTY)) != -1) {
 	    if ((len = lseek(fd, 0, 2)) != -1) {

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: functrace and funcsourcetrace (was Re: PATCH: trace information for sourced files)

[Mikael Magnusson]

2008/8/22 Peter Stephenson <pws@csr.com>:
> On Mon, 18 Aug 2008 13:13:39 +0200
> "Mikael Magnusson" <mikachu@gmail.com> wrote:
>> The current cvs zsh crashes for me on any tabcompletion now iff i've
>> done a zcompile on the functions dir in /usr/local/share/zsh/blabla.
>> The first commit with the crash is "25247 with further modifications:
>> add $funcsourcetrace":
>>
>> % cd<tab>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x41b6624b in strlen () from /lib/libc.so.6
>> (gdb) bt
>> #0  0x41b6624b in strlen () from /lib/libc.so.6
>> #1  0x080bfb10 in dupstring (s=0x3cff9c3 <Address 0x3cff9c3 out of
>> bounds>) at string.c:39
>> #2  0x08073673 in execautofn (state=0xaf92bf1c, do_exec=0) at exec.c:4075
>
> Looking at this part of the trace, I wonder if this is the problem?

I think that fixed it, but I'm a bit tired right now so I'm not 100% sure
I recompiled everything correctly :).

-- 
Mikael Magnusson