cscope-devel

Re: [Cscope-devel] cscope aborts at exit due to myexit() recursive call

[Vladis D. <vd...@re...>]

I'm sorry for the flood in the list.

I've tried to post a message and it has not appeared in the list interface
after I've waited for 24+ hours:
https://sourceforge.net/p/cscope/mailman/cscope-devel/?viewmonth=202408

I thought it was rejected due to attachments. I've re-send my message
without
attachments, still nothing. So, I've subscribed to the list and have sent my
message from a subscribed email address. That single message has appeared.

Now, a day after I see all 3 of my messages in the list interface. This was
not
intended. I'm sorry for the mess and the flood.

Best regards,
Vladis

Re: [Cscope-devel] cscope aborts at exit due to myexit() recursive call

[Elad L. <e2...@gm...>]

The code is definitely wrong in making non-async-signal-safe calls in
a signal handler. The signal handlers should set some flag and let the
main loop know that it should exit.

--Elad

On Tue, Aug 6, 2024 at 8:45 AM Vladis Dronov <vd...@re...> wrote:
>
> i know this is a dead list, so i'm sorry for a necro posting into a gray
> void.
>
> still, we see cscope aborts at exit due to myexit() recursive call. we have
> 2 cases, see backtraces attached
> (i have no idea if this list@ accepts these attachments). also see the
> following for details:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2269887#c15 - research
> - an ugly fix
>
> so a research shows that the cscope process attempted a normal exit (by "q"
> or Ctrl-D) calling myexit(0).
> in the middle of it a signal SIGHUP handler was called, which is myexit()
> itself. then glibc detects a
> double-free condition in __GI___libc_free() while performing
> fclose(refsfound). then glibc aborts the process
> with __GI_abort() and the "free(): double free detected in tcache 2"
> message. backtraces we have are:
>
> main.c:847 in main(): /* normal quit */ myexit(0); ->
>   main.c:1079 in myexit(sig=0): freefilelist(); ->
>     dir.c:727 in in freefilelist(): free(srcfiles[--nsrcfiles]); ->
>       malloc.c:3352 in __GI___libc_free() ->
>         <signal handler called> ->
>           main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
>             iofclose.c:74 in _IO_new_fclose() -> ... ->
>               malloc.c:3391 in __GI___libc_free() ->
>                 malloc_printerr("free(): double free detected in tcache 2")
> -> __GI_abort()
>
> main.c:847 in main(): /* normal quit */ myexit(0); ->
>   main.c:1066 in myexit(sig=0): unlink(temp1); ->
>     unlink.c:28 __unlink (name=<temp1> "/tmp/cscope.699047/cscope.1"); ->
>       <signal handler called> ->
>         main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
>           iofclose.c:74 in _IO_new_fclose() -> ... ->
>             malloc.c:3391 in __GI___libc_free() ->
>               malloc_printerr("free(): double free detected in tcache 2")
> -> __GI_abort()
>
> in a short word, a process abort is caused by myexit() interrupted by a
> signal which handler is myexit() itself.
>
> note, free() and fclose() are NOT async-signal-safe, see "man 7
> signal-safety". calling an async-signal-unsafe
> function from a signal handler is perfectly legal unless the signal
> interrupted another async-signal-unsafe function.
> so i'm not sure about the unlink() case, unlink() is async-signal-safe.
> still, the double-free condition is still
> there, as we can see from the backtrace.
>
> i'm not going to fix the whole signal handling in cscope, as it is broken.
> 1) myexit() calls functions which are
> not async-signal-safe 2) signal() infrastructure (which is broken) is used
> instead of sigaction(). i'll fix only
> this specific case where myexit() is interrupted by a call to myexit()
> itself by resetting signal handlers to
> default ones. this may be not entirely correct but whatever.
>
> Best regards,
> Vladis
>
> ---
>
> diff -up ./src/main.c.orig ./src/main.c
> --- ./src/main.c.orig 2024-08-04 16:49:08.723525637 +0200
> +++ ./src/main.c 2024-08-04 16:53:19.967862016 +0200
> @@ -1056,11 +1056,18 @@ Please see the manpage for more informat
>  void
>  myexit(int sig)
>  {
> + /* reset signal handlers to default ones, so myexit() is not called
> + * recursively as a signal handler during a normal exit */
> + signal(SIGINT, SIG_DFL);
> + signal(SIGQUIT, SIG_DFL);
> + signal(SIGHUP, SIG_DFL);
> + signal(SIGTERM, SIG_DFL);
> +
>   /* HBB 20010313; close file before unlinking it. Unix may not care
>   * about that, but DOS absolutely needs it */
>   if (refsfound != NULL)
>   fclose(refsfound);
> -
> +
>   /* remove any temporary files */
>   if (temp1[0] != '\0') {
>   unlink(temp1);
> _______________________________________________
> Cscope-devel mailing list
> Csc...@li...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel

[Cscope-devel] cscope aborts at exit due to myexit() recursive call by a signal

[Владислав Д. <vdr...@gm...>]

hi,
know this is a sort of an inactive list, so i'm sorry for necroposting into
a void.

still, we see cscope aborts at exit due to myexit() recursive call. we have
2 cases, see backtraces in
bugzillas mentioned:

https://bugzilla.redhat.com/show_bug.cgi?id=2269887 - report 1 and a
research
https://bugzilla.redhat.com/show_bug.cgi?id=2256515 - report 2
https://src.fedoraproject.org/rpms/cscope/c/a4d105ed18317c43e41fd20934509f8f250edc68?branch=rawhide
- an ugly fix

so a research shows that the cscope process attempted a normal exit (by "q"
or Ctrl-D) calling myexit(0).
in the middle of it a signal SIGHUP handler was called, which is myexit()
itself. then glibc detects a
double-free condition in __GI___libc_free() while performing
fclose(refsfound). then glibc aborts the process
with __GI_abort() and the "free(): double free detected in tcache 2"
message. backtraces we have are:

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1079 in myexit(sig=0): freefilelist(); ->
    dir.c:727 in in freefilelist(): free(srcfiles[--nsrcfiles]); ->
      malloc.c:3352 in __GI___libc_free() ->
        <signal handler called> ->
          main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
            iofclose.c:74 in _IO_new_fclose() -> ... ->
              malloc.c:3391 in __GI___libc_free() ->
                malloc_printerr("free(): double free detected in tcache 2")
-> __GI_abort()

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1066 in myexit(sig=0): unlink(temp1); ->
    unlink.c:28 __unlink (name=<temp1> "/tmp/cscope.699047/cscope.1"); ->
      <signal handler called> ->
        main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
          iofclose.c:74 in _IO_new_fclose() -> ... ->
            malloc.c:3391 in __GI___libc_free() ->
              malloc_printerr("free(): double free detected in tcache 2")
-> __GI_abort()

in a short word, a process abort is caused by myexit() interrupted by a
signal which handler is myexit() itself.

note, free() and fclose() are NOT async-signal-safe, see "man 7
signal-safety". calling an async-signal-unsafe
function from a signal handler is perfectly legal unless the signal
interrupted another async-signal-unsafe function.
so i'm not sure about the unlink() case, unlink() is async-signal-safe.
still, the double-free condition is still
there, as we can see from the backtrace.

i'm not going to fix the whole signal handling in cscope, as it seems
broken. 1) myexit() calls functions which are
not async-signal-safe 2) signal() infrastructure (which is broken) is used
instead of sigaction(). i'll ugly-fix only
this specific case where myexit() is interrupted by a call to myexit()
itself by resetting signal handlers to default
ones. this may be not entirely correct but whatever.

Best regards,
Vladis

---

diff -up ./src/main.c.orig ./src/main.c
--- ./src/main.c.orig 2024-08-04 16:49:08.723525637 +0200
+++ ./src/main.c 2024-08-04 16:53:19.967862016 +0200
@@ -1056,11 +1056,18 @@ Please see the manpage for more informat
 void
 myexit(int sig)
 {
+ /* reset signal handlers to default ones, so myexit() is not called
+ * recursively as a signal handler during a normal exit */
+ signal(SIGINT, SIG_DFL);
+ signal(SIGQUIT, SIG_DFL);
+ signal(SIGHUP, SIG_DFL);
+ signal(SIGTERM, SIG_DFL);
+
  /* HBB 20010313; close file before unlinking it. Unix may not care
  * about that, but DOS absolutely needs it */
  if (refsfound != NULL)
  fclose(refsfound);
-
+
  /* remove any temporary files */
  if (temp1[0] != '\0') {
  unlink(temp1);

[Cscope-devel] cscope aborts at exit due to myexit() recursive call by a signal

[Vladis D. <vd...@re...>]

i know this is a sort of an inactive list, so i'm sorry for necroposting
into a void.

still, we see cscope aborts at exit due to myexit() recursive call. we have
2 cases, see backtraces in
bugzillas mentioned:

https://bugzilla.redhat.com/show_bug.cgi?id=2269887 - report 1 and a
research
https://bugzilla.redhat.com/show_bug.cgi?id=2256515 - report 2
https://src.fedoraproject.org/rpms/cscope/c/a4d105ed18317c43e41fd20934509f8f250edc68?branch=rawhide
- an ugly fix

so a research shows that the cscope process attempted a normal exit (by "q"
or Ctrl-D) calling myexit(0).
in the middle of it a signal SIGHUP handler was called, which is myexit()
itself. then glibc detects a
double-free condition in __GI___libc_free() while performing
fclose(refsfound). then glibc aborts the process
with __GI_abort() and the "free(): double free detected in tcache 2"
message. backtraces we have are:

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1079 in myexit(sig=0): freefilelist(); ->
    dir.c:727 in in freefilelist(): free(srcfiles[--nsrcfiles]); ->
      malloc.c:3352 in __GI___libc_free() ->
        <signal handler called> ->
          main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
            iofclose.c:74 in _IO_new_fclose() -> ... ->
              malloc.c:3391 in __GI___libc_free() ->
                malloc_printerr("free(): double free detected in tcache 2")
-> __GI_abort()

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1066 in myexit(sig=0): unlink(temp1); ->
    unlink.c:28 __unlink (name=<temp1> "/tmp/cscope.699047/cscope.1"); ->
      <signal handler called> ->
        main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
          iofclose.c:74 in _IO_new_fclose() -> ... ->
            malloc.c:3391 in __GI___libc_free() ->
              malloc_printerr("free(): double free detected in tcache 2")
-> __GI_abort()

in a short word, a process abort is caused by myexit() interrupted by a
signal which handler is myexit() itself.

note, free() and fclose() are NOT async-signal-safe, see "man 7
signal-safety". calling an async-signal-unsafe
function from a signal handler is perfectly legal unless the signal
interrupted another async-signal-unsafe function.
so i'm not sure about the unlink() case, unlink() is async-signal-safe.
still, the double-free condition is still
there, as we can see from the backtrace.

i'm not going to fix the whole signal handling in cscope, as it seems
broken. 1) myexit() calls functions which are
not async-signal-safe 2) signal() infrastructure (which is broken) is used
instead of sigaction(). i'll ugly-fix only
this specific case where myexit() is interrupted by a call to myexit()
itself by resetting signal handlers to default
ones. this may be not entirely correct but whatever.

Best regards,
Vladis

---

diff -up ./src/main.c.orig ./src/main.c
--- ./src/main.c.orig 2024-08-04 16:49:08.723525637 +0200
+++ ./src/main.c 2024-08-04 16:53:19.967862016 +0200
@@ -1056,11 +1056,18 @@ Please see the manpage for more informat
 void
 myexit(int sig)
 {
+ /* reset signal handlers to default ones, so myexit() is not called
+ * recursively as a signal handler during a normal exit */
+ signal(SIGINT, SIG_DFL);
+ signal(SIGQUIT, SIG_DFL);
+ signal(SIGHUP, SIG_DFL);
+ signal(SIGTERM, SIG_DFL);
+
  /* HBB 20010313; close file before unlinking it. Unix may not care
  * about that, but DOS absolutely needs it */
  if (refsfound != NULL)
  fclose(refsfound);
-
+
  /* remove any temporary files */
  if (temp1[0] != '\0') {
  unlink(temp1);

[Cscope-devel] cscope aborts at exit due to myexit() recursive call

[Vladis D. <vd...@re...>]

i know this is a dead list, so i'm sorry for a necro posting into a gray
void.

still, we see cscope aborts at exit due to myexit() recursive call. we have
2 cases, see backtraces attached
(i have no idea if this list@ accepts these attachments). also see the
following for details:

https://bugzilla.redhat.com/show_bug.cgi?id=2269887#c15 - research
- an ugly fix

so a research shows that the cscope process attempted a normal exit (by "q"
or Ctrl-D) calling myexit(0).
in the middle of it a signal SIGHUP handler was called, which is myexit()
itself. then glibc detects a
double-free condition in __GI___libc_free() while performing
fclose(refsfound). then glibc aborts the process
with __GI_abort() and the "free(): double free detected in tcache 2"
message. backtraces we have are:

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1079 in myexit(sig=0): freefilelist(); ->
    dir.c:727 in in freefilelist(): free(srcfiles[--nsrcfiles]); ->
      malloc.c:3352 in __GI___libc_free() ->
        <signal handler called> ->
          main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
            iofclose.c:74 in _IO_new_fclose() -> ... ->
              malloc.c:3391 in __GI___libc_free() ->
                malloc_printerr("free(): double free detected in tcache 2")
-> __GI_abort()

main.c:847 in main(): /* normal quit */ myexit(0); ->
  main.c:1066 in myexit(sig=0): unlink(temp1); ->
    unlink.c:28 __unlink (name=<temp1> "/tmp/cscope.699047/cscope.1"); ->
      <signal handler called> ->
        main.c:1062 in myexit (sig=1 SIGHUP ): fclose(refsfound); ->
          iofclose.c:74 in _IO_new_fclose() -> ... ->
            malloc.c:3391 in __GI___libc_free() ->
              malloc_printerr("free(): double free detected in tcache 2")
-> __GI_abort()

in a short word, a process abort is caused by myexit() interrupted by a
signal which handler is myexit() itself.

note, free() and fclose() are NOT async-signal-safe, see "man 7
signal-safety". calling an async-signal-unsafe
function from a signal handler is perfectly legal unless the signal
interrupted another async-signal-unsafe function.
so i'm not sure about the unlink() case, unlink() is async-signal-safe.
still, the double-free condition is still
there, as we can see from the backtrace.

i'm not going to fix the whole signal handling in cscope, as it is broken.
1) myexit() calls functions which are
not async-signal-safe 2) signal() infrastructure (which is broken) is used
instead of sigaction(). i'll fix only
this specific case where myexit() is interrupted by a call to myexit()
itself by resetting signal handlers to
default ones. this may be not entirely correct but whatever.

Best regards,
Vladis

---

diff -up ./src/main.c.orig ./src/main.c
--- ./src/main.c.orig 2024-08-04 16:49:08.723525637 +0200
+++ ./src/main.c 2024-08-04 16:53:19.967862016 +0200
@@ -1056,11 +1056,18 @@ Please see the manpage for more informat
 void
 myexit(int sig)
 {
+ /* reset signal handlers to default ones, so myexit() is not called
+ * recursively as a signal handler during a normal exit */
+ signal(SIGINT, SIG_DFL);
+ signal(SIGQUIT, SIG_DFL);
+ signal(SIGHUP, SIG_DFL);
+ signal(SIGTERM, SIG_DFL);
+
  /* HBB 20010313; close file before unlinking it. Unix may not care
  * about that, but DOS absolutely needs it */
  if (refsfound != NULL)
  fclose(refsfound);
-
+
  /* remove any temporary files */
  if (temp1[0] != '\0') {
  unlink(temp1);

[Cscope-devel] [PATCH] make it possible to add the new keywords

[Oleg N. <ol...@re...>]

The linux kernel uses a lot of annotations which confuse cscope.
Simple example:

	$ cat -n test.c
	     1	void func1(void) __acquires(RCU)
	     2	{
	     3		X = 1;
	     4	}
	     5
	     6	void func2(void) __releases(RCU)
	     7	{
	     8		X = 1;
	     9	}
	$ ./cscope -bu test.c
	$ ./cscope -dL -0 X
	test.c __acquires 3 X = 1;
	test.c __releases 8 X = 1;

With this patch below we can do

	$ ./cscope -bu -K __acquires,__releases test.c

and

	$ ./cscope -dL -0 X
	test.c func1 3 X = 1;
	test.c func2 8 X = 1;

looks much better to me.

Signed-off-by: Oleg Nesterov <ol...@re...>
---
 src/global.h |  1 +
 src/lookup.c | 35 +++++++++++++++++++++++++++++++----
 src/main.c   |  5 ++++-
 3 files changed, 36 insertions(+), 5 deletions(-)

diff --git a/src/global.h b/src/global.h
index a6f1486..5f75b68 100644
--- a/src/global.h
+++ b/src/global.h
@@ -342,6 +342,7 @@ char	*read_block(void);
 char	*scanpast(char c);
 
 
+void	add_keyword(char *csk);
 void	addcmd(int f, char *s);
 void	addsrcfile(char *path);
 void	askforchar(void);
diff --git a/src/lookup.c b/src/lookup.c
index d8595db..71e4aac 100644
--- a/src/lookup.c
+++ b/src/lookup.c
@@ -51,7 +51,9 @@ char	uniontext[] = "union";
  * without changing the database file version and adding compatibility code
  * for old databases.
  */
-struct	keystruct keyword[] = {
+#define KEYWORDS	64
+
+struct	keystruct keyword[KEYWORDS] = {
 	{"",		'\0',	NULL},	/* dummy entry */
 	{"#define",	' ',	NULL},	/* must be table entry 1 */
 	{"#include",	' ',	NULL},	/* must be table entry 2 */
@@ -93,7 +95,32 @@ struct	keystruct keyword[] = {
 	{"signed",	' ',	NULL},
 	{"volatile",	' ',	NULL},
 };
-#define KEYWORDS	(sizeof(keyword) / sizeof(keyword[0]))
+
+static int keyword_nr = 38;
+
+void add_keyword(char *csk)
+{
+	for (;;) {
+		char *eok = strchrnul(csk, ',');
+		int last = !*eok;
+
+		*eok = 0;
+		if (*csk) {
+			if (keyword_nr == KEYWORDS) {
+				fprintf(stderr, "KEYWORDS overflow\n");
+				myexit(1);
+			}
+			keyword[keyword_nr].text = csk;
+			keyword[keyword_nr].delim = '(';
+			keyword_nr++;
+		}
+
+		if (last)
+			break;
+		csk = eok + 1;
+	}
+}
+
 
 #define HASHMOD	(KEYWORDS * 2 + 1)
 
@@ -106,8 +133,8 @@ initsymtab(void)
 {
     unsigned int i, j;
     struct keystruct *p;
-	
-    for (i = 1; i < KEYWORDS; ++i) {
+
+    for (i = 1; i < keyword_nr; ++i) {
 	p = keyword + i;
 	j = hash(p->text) % HASHMOD;
 	p->next = hashtab[j];
diff --git a/src/main.c b/src/main.c
index 2ffabc3..055b222 100644
--- a/src/main.c
+++ b/src/main.c
@@ -153,7 +153,7 @@ char ** parse_options(int *argc, char **argv)
 	
 
 	while ((opt = getopt_long(argcc, argv,
-	       "hVbcCdeF:f:I:i:kLl0:1:2:3:4:5:6:7:8:9:P:p:qRs:TUuvX",
+	       "hVbcCdeF:f:I:i:kLl0:1:2:3:4:5:6:7:8:9:P:p:qRs:TUuvXK:",
 	       lopts, &longind)) != -1) {
 		switch(opt) {
 
@@ -273,6 +273,9 @@ char ** parse_options(int *argc, char **argv)
 		case 's':	/* additional source file directory */
 			sourcedir(optarg);
 			break;
+		case 'K':
+			add_keyword(optarg);
+			break;
 		}
 	}
 	/*
-- 
2.25.1.362.g51ebf55

[Cscope-devel] [PATCH] correct the erroneous brace count caused by the unbalanced \{|\}

[Oleg N. <ol...@re...>]

cscope can't parse kernel/trace/trace_events.c (and some other files)
in the linux kernel tree because this file has

	#define do_for_each_event_file(tr, file)			\
		list_for_each_entry(tr, &ftrace_trace_arrays, list) {	\
			list_for_each_entry(file, &tr->events, list)

	#define do_for_each_event_file_safe(tr, file)			\
		list_for_each_entry(tr, &ftrace_trace_arrays, list) {	\
			struct trace_event_file *___n;				\
			list_for_each_entry_safe(file, ___n, &tr->events, list)

	#define while_for_each_event_file()		\
		}

at the top and thus the 2nd '{' in do_for_each_event_file_safe() above
is not balanced.

Signed-off-by: Oleg Nesterov <ol...@re...>
---
 src/fscanner.l | 70 ++++++++++++++++++++++++++------------------------
 1 file changed, 37 insertions(+), 33 deletions(-)

diff --git a/src/fscanner.l b/src/fscanner.l
index 43880bf..46734ea 100644
--- a/src/fscanner.l
+++ b/src/fscanner.l
@@ -178,19 +178,21 @@ wsnl		[ \t\r\v\f\n]|{comment}
 		}
 
 \{		{	/* count unmatched left braces for fcn def detection */
-			++braces;
-			
-			/* mark an untagged enum/struct/union so its beginning
-			   can be found */
-			if (tagdef) {
-				if (braces == 1) {
-					esudef = YES;
+			if (ppdefine == NO) {
+				++braces;
+
+				/* mark an untagged enum/struct/union so its beginning
+				   can be found */
+				if (tagdef) {
+					if (braces == 1) {
+						esudef = YES;
+					}
+					token = tagdef;
+					tagdef = '\0';
+					last = first;
+					my_yymore();
+					return(token);
 				}
-				token = tagdef;
-				tagdef = '\0';
-				last = first;
-				my_yymore();
-				return(token);
 			}
 			goto more;
 			/* NOTREACHED */
@@ -326,28 +328,30 @@ wsnl		[ \t\r\v\f\n]|{comment}
 		}
 
 \}		{
-			/* could be the last enum member initializer */
-			if (braces == initializerbraces) {
-				initializerbraces = -1;
-				initializer = NO;
-			}
-			if (--braces <= 0) {
-		endstate:
-				braces = 0;
-				classdef = NO;
-			}
-			if (braces == 0 || (braces == 1 && classdef == YES)) {
-
-				/* if the end of an enum/struct/union definition */
-				if (esudef == YES) {
-					esudef = NO;
+			if (ppdefine == NO) {
+				/* could be the last enum member initializer */
+				if (braces == initializerbraces) {
+					initializerbraces = -1;
+					initializer = NO;
 				}
-				/* if the end of the function */
-				else if (fcndef == YES) {
-					fcndef = NO;
-					last = first;
-					my_yymore();
-					return(FCNEND);
+				if (--braces <= 0) {
+			endstate:
+					braces = 0;
+					classdef = NO;
+				}
+				if (braces == 0 || (braces == 1 && classdef == YES)) {
+
+					/* if the end of an enum/struct/union definition */
+					if (esudef == YES) {
+						esudef = NO;
+					}
+					/* if the end of the function */
+					else if (fcndef == YES) {
+						fcndef = NO;
+						last = first;
+						my_yymore();
+						return(FCNEND);
+					}
 				}
 			}
 			goto more;
-- 
2.25.1.362.g51ebf55

Re: [Cscope-devel] [patch] fix crash with cscope-15.9 on macOS + typo fixes

[Dominique P. <dom...@gm...>]

Hans-Bernhard Bröker wrote:

> Am 01.05.2022 um 13:38 schrieb Dominique Pellé:
> > Hi
> >
> > cscope-15.9 (installed from homebrew) crashes on macOS (Monterey).
>
> That's somewhat surprising insofar as it's the first such report in 4
> years since we released 15.9, except for a build failure that was
> apparently due to some breakage in Apple's latest version of their
> development tool chain.
>
> > ==50182==ERROR: AddressSanitizer: global-buffer-overflow on address
> > 0x00010474cc81 at pc 0x00010d195718 bp 0x00030d14ae90 sp
> [...]> 0x00010474cc81 is located 0 bytes to the right of global variable
> > 'found_caller' defined in 'find.c:1047:14' (0x10474cc80) of size 1
>
>
> [...]
> > I can reproduce the crash at least with vim sources:
>
> Which version of the vim source, in particular?
>
> > The proposed patch fixes that issue in `find.c` by making sure
> > the returned `char*` is '\0' terminated.
>
> The patch would be much easier to digest if it did just that, instead of
> conflating it with other, unrelated changes.  Changes for 3 separate
> issues really should come as 3 patch files.
>
> That said, it might be even better if you could use the "Patches"
> tracker at SourceForge for them.
>
> > However, cscope still did not work on macOS for another
> > reason whereas it worked on Linux.
>
> "Did not work" begs for a better explanation.
>
> I do see test failures here in vim's "make test_cscope" of the GIT head
> version.  But those look like they're more likely to have been caused by
> bit-rot in the tests' expected results.  The results themselves appear
> correct.
>
> > Debugging the difference,
> > I saw that BUFSIZ is 1024 on macOS and 8192 on Linux and
> > somehow this causes cscope to not work on macOS.
>
> That is an extremely surprising finding, given that cscope reportedly
> has worked on MacOS just fine, for a very long time.
>
> Also, other platforms that use a BUFSIZ of 1024 have worked just fine,
> too.  Including Cygwin, which is my primary cscope platform these days.
>   That make me doubt this analysis heavily.
>
> > I wanted to try with the latest code in CVS but
> > I was not able to download it from sourceforge.
>
> CVS has been discontinued by SourceForge.  The source is now in git there.

Hi

I just created 3 separate git pull requests:

* https://sourceforge.net/p/cscope/cscope/merge-requests/3/
  This pull requests fixes access beyond end of string reproducible
  on macOS or Linux.  On Linux it crashes only when cscope
  is built with the address sanitizer (asan) but on macOS Monterey M1
  it crashed even in regular build and crashed with the official
  homebrew binary package.  See reproducible steps [1] below.

* https://sourceforge.net/p/cscope/cscope/merge-requests/4/
  This pull request merely fixes typos in the man page and
  in source code comments.

* https://sourceforge.net/p/cscope/cscope/merge-requests/5/
  This pull request fixes Vim cscope test.  See reproducible steps
  [2] below on macOS. It should be applied on top of
  https://sourceforge.net/p/cscope/cscope/merge-requests/3/
  The bug in this last PR is not so clear and deserves more
  investigation but my PR makes Vim test works at least.


[1] steps to reproduce asan error on Linux or macOS, happening
with latest scope in git without my PRs
https://sourceforge.net/p/cscope/cscope/merge-requests/3/
```
# git SHA1 of latest scope: eaea31cb93ecddda69a373f83f632e1a450c3c90
$ git clone https://git.code.sf.net/p/cscope/cscope cscope-cscope
$ cd cscope-cscope
$ autoreconf -i -s

# Configure to build with asan (address sanitizer) to find invalid
memory acceses
$ CFLAGS="-O0 -fsanitize=address" LDFLAGS="-O0 -fsanitize=address" ./configure
$ make
$ cd src
$ rm -f cscope.out ; ./cscope -bk -fcscope.out main.c
$ ./cscope -d 2> asan.log

# Then in the scope UI, search for xxx (a non-existing function) with:
Find functions called by this function: xxx

Observe that scsope crashes and asan.log file contains:
```
=================================================================
==6590==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00000074b121 at pc 0x7f269ef5f653 bp 0x7ffc9ca95630 sp
0x7ffc9ca94de0
READ of size 2 at 0x00000074b121 thread T0
    #0 0x7f269ef5f652  (/usr/local/pkg/gcc5/lib/../lib64/libasan.so.2+0x5f652)
    #1 0x7f269ef603b6 in __interceptor_vsnprintf
(/usr/local/pkg/gcc5/lib/../lib64/libasan.so.2+0x603b6)
    #2 0x7f269ef60605 in __interceptor_snprintf
(/usr/local/pkg/gcc5/lib/../lib64/libasan.so.2+0x60605)
    #3 0x422f51 in search (/home/dope/sb/cscope-cscope/src/cscope+0x422f51)
    #4 0x417763 in command (/home/dope/sb/cscope-cscope/src/cscope+0x417763)
    #5 0x43610f in main (/home/dope/sb/cscope-cscope/src/cscope+0x43610f)
    #6 0x7f269e4e1c86 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
    #7 0x4037d9 in _start (/home/dope/sb/cscope-cscope/src/cscope+0x4037d9)

0x00000074b121 is located 0 bytes to the right of global variable
'found_caller' defined in 'find.c:1047:14' (0x74b120) of size 1
0x00000074b121 is located 63 bytes to the left of global variable
'function' defined in 'find.c:1204:14' (0x74b160) of size 251
SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x0000800e15d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800e15e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800e15f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800e1600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800e1610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
=>0x0000800e1620: f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x0000800e1630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800e1640: 00 00 00 00 00 00 00 00 00 00 00 03 f9 f9 f9 f9
  0x0000800e1650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800e1660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800e1670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==6590==ABORTING
```

[2] steps to reproduce Vim cscope failing test
on macOS only (on Linux test passed) without
my PR https://sourceforge.net/p/cscope/cscope/merge-requests/5/

Make sure cscope is in PATH then:
```
# git SHA1 of latest vim: d899e51120798d3fb5420abb1f19dddf3f014d05
$ git clone https://github.com/vim/vim.git
$ cd vim
$ ./configure --with-features=huge --enable-gui=none --enable-cscope
--enable-fail-if-missing
$ make -j8
$ cd src/testdir
$ make test_cscope
...snip...
>From test_cscope.vim:
Executed Test_cscopeWithCscopeConnections()        in   0.558636 seconds
Executed Test_cscope_add_dir()                     in   0.175729 seconds
Executed Test_cscopequickfix()                     in   0.000320 seconds
Executed Test_withoutCscopeConnection()            in   0.000226 seconds
Executed 4 tests                         in   0.759186 seconds
2 FAILED:
Found errors in Test_cscopeWithCscopeConnections():
Caught exception in Test_cscopeWithCscopeConnections():
Vim(cscope):E262: Error reading cscope connection 0 @ command
line..script /private/tmp/vim/src/testdir/runtest.vim[459]..function
RunTheTest[44]..Test_cscopeWithCscopeConnections, line 36
Found errors in Test_cscope_add_dir():
command line..script
/private/tmp/vim/src/testdir/runtest.vim[459]..function
RunTheTest[44]..Test_cscope_add_dir line 11: Expected 3 but got 4
command line..script
/private/tmp/vim/src/testdir/runtest.vim[459]..function
RunTheTest[44]..Test_cscope_add_dir line 14: Pattern '^ 0
\\d\\+.*Xcscopedir/cscope.out\\s\\+<none>$' does not match ' 0 25431
/private/tmp/vim/src/testdir/Xcscope.out  <none>'
make: *** [Makefile:66: test_cscope] Error 1
```

Regards
Dominique

Re: [Cscope-devel] [patch] fix crash with cscope-15.9 on macOS + typo fixes

[Hans-Bernhard B. <HBB...@t-...>]

Am 01.05.2022 um 13:38 schrieb Dominique Pellé:
> Hi
> 
> cscope-15.9 (installed from homebrew) crashes on macOS (Monterey).

That's somewhat surprising insofar as it's the first such report in 4 
years since we released 15.9, except for a build failure that was 
apparently due to some breakage in Apple's latest version of their 
development tool chain.


> ==50182==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x00010474cc81 at pc 0x00010d195718 bp 0x00030d14ae90 sp
[...]> 0x00010474cc81 is located 0 bytes to the right of global variable
> 'found_caller' defined in 'find.c:1047:14' (0x10474cc80) of size 1


[...]
> I can reproduce the crash at least with vim sources:

Which version of the vim source, in particular?

> The proposed patch fixes that issue in `find.c` by making sure
> the returned `char*` is '\0' terminated.

The patch would be much easier to digest if it did just that, instead of
conflating it with other, unrelated changes.  Changes for 3 separate 
issues really should come as 3 patch files.

That said, it might be even better if you could use the "Patches" 
tracker at SourceForge for them.

> However, cscope still did not work on macOS for another
> reason whereas it worked on Linux. 

"Did not work" begs for a better explanation.

I do see test failures here in vim's "make test_cscope" of the GIT head 
version.  But those look like they're more likely to have been caused by 
bit-rot in the tests' expected results.  The results themselves appear 
correct.

> Debugging the difference,
> I saw that BUFSIZ is 1024 on macOS and 8192 on Linux and
> somehow this causes cscope to not work on macOS.

That is an extremely surprising finding, given that cscope reportedly 
has worked on MacOS just fine, for a very long time.

Also, other platforms that use a BUFSIZ of 1024 have worked just fine, 
too.  Including Cygwin, which is my primary cscope platform these days. 
  That make me doubt this analysis heavily.

> I wanted to try with the latest code in CVS but
> I was not able to download it from sourceforge.

CVS has been discontinued by SourceForge.  The source is now in git there.

Re: [Cscope-devel] [patch] fix crash with cscope-15.9 on macOS + typo fixes

[Dominique P. <dom...@gm...>]

Dominique Pellé wrote:

> The proposed patch fixes that issue in `find.c` by making sure
> the returned `char*` is '\0' terminated.
...snip...
> The proposed patch also fixes unrelated typos in
> comments and in the cscope man pages.
...snip...

I do not see that patch that I attached in my previous
message in the mailing list archive. I suppose that
attachments are not permitted.

I therefore put the patch inline below (the important
part for the bug fix is in find.c):

diff -c -r cscope-15.9/doc/xcscope.1 cscope-15.9-fixed/doc/xcscope.1
*** cscope-15.9/doc/xcscope.1    2017-11-07 01:14:58.000000000 +0100
--- cscope-15.9-fixed/doc/xcscope.1    2022-05-01 08:11:24.000000000 +0200
***************
*** 1,6 ****
  '\" t
  .\" The xcscope.el man page
! .\" Origionally written by Darryl Okahata, Apr 2000
  .\"
  .\" Converted to a man page July 20, 2004 by Neil Horman <nh...@re...>
  .\"
--- 1,6 ----
  '\" t
  .\" The xcscope.el man page
! .\" Originally written by Darryl Okahata, Apr 2000
  .\"
  .\" Converted to a man page July 20, 2004 by Neil Horman <nh...@re...>
  .\"
***************
*** 152,158 ****
  .P
  If a search is initiated from a .c file in /users/jdoe/sources/proj1
  then (assuming the variable, `cscope-database-regexps', is not set)
! /users/jdoe/sources/proj1 will be used as the cscope data base directory.
  Only matches in files in /users/jdoe/sources/proj1 will be found.  This
  can be remedied by typing "C-c s a" and then "M-del" to remove single
  path element in order to use a cscope database directory of
--- 152,158 ----
  .P
  If a search is initiated from a .c file in /users/jdoe/sources/proj1
  then (assuming the variable, `cscope-database-regexps', is not set)
! /users/jdoe/sources/proj1 will be used as the cscope database directory.
  Only matches in files in /users/jdoe/sources/proj1 will be found.  This
  can be remedied by typing "C-c s a" and then "M-del" to remove single
  path element in order to use a cscope database directory of
***************
*** 173,179 ****
  C-c s g       Find global definition (alternate binding).
  C-c s G       Find global definition without prompting.
  C-c s c       Find functions calling a function.
! C-c s C       Find called functions (list functions called
  C-c s t       Find text string.
  C-c s e       Find egrep pattern.
  C-c s f       Find a file.
--- 173,179 ----
  C-c s g       Find global definition (alternate binding).
  C-c s G       Find global definition without prompting.
  C-c s c       Find functions calling a function.
! C-c s C       Find called functions (list functions called)
  C-c s t       Find text string.
  C-c s e       Find egrep pattern.
  C-c s f       Find a file.
***************
*** 527,533 ****

  .P
  1. The script, "cscope-indexer", uses a sed command to determine
! what is and is not a C/C++/lex/yacc source file.  It's idea of a
  source file may not correspond to yours.

  .P
--- 527,533 ----

  .P
  1. The script, "cscope-indexer", uses a sed command to determine
! what is and is not a C/C++/lex/yacc source file.  Its idea of a
  source file may not correspond to yours.

  .P
diff -c -r cscope-15.9/src/build.c cscope-15.9-fixed/src/build.c
*** cscope-15.9/src/build.c    2017-11-07 01:14:58.000000000 +0100
--- cscope-15.9-fixed/src/build.c    2022-05-01 12:57:15.000000000 +0200
***************
*** 133,139 ****
  }


! /* create the file name(s) used for a new cross-referene */

  void setup_build_filenames(char *reffile)
  {
--- 133,139 ----
  }


! /* create the file name(s) used for a new cross-reference */

  void setup_build_filenames(char *reffile)
  {
diff -c -r cscope-15.9/src/command.c cscope-15.9-fixed/src/command.c
*** cscope-15.9/src/command.c    2018-07-19 21:45:17.000000000 +0200
--- cscope-15.9-fixed/src/command.c    2022-05-01 08:05:54.000000000 +0200
***************
*** 887,893 ****
      filelen = 4;        /* strlen("File") */
      fcnlen = 8;        /* strlen("Function") */
      numlen = 0;
!     /* HBB NOTE 2012-04-07: it may look like we shouldn't assing
tempstring here,
       * since it's not used.  But it has to be assigned just so the
return value
       * of fscanf will actually reach 4. */
      while (EOF != (i = fscanf(refsfound,
--- 887,893 ----
      filelen = 4;        /* strlen("File") */
      fcnlen = 8;        /* strlen("Function") */
      numlen = 0;
!     /* HBB NOTE 2012-04-07: it may look like we shouldn't assigning
tempstring here,
       * since it's not used.  But it has to be assigned just so the
return value
       * of fscanf will actually reach 4. */
      while (EOF != (i = fscanf(refsfound,
diff -c -r cscope-15.9/src/compath.c cscope-15.9-fixed/src/compath.c
*** cscope-15.9/src/compath.c    2017-11-07 01:14:58.000000000 +0100
--- cscope-15.9-fixed/src/compath.c    2022-05-01 08:04:51.000000000 +0200
***************
*** 40,46 ****
   *
   *    WARNING: since pathname is altered by this function, it should
   *         be located in a temporary buffer. This avoids the problem
!  *         of accidently changing strings obtained from makefiles
   *         and stored in global structures.
   */

--- 40,46 ----
   *
   *    WARNING: since pathname is altered by this function, it should
   *         be located in a temporary buffer. This avoids the problem
!  *         of accidentally changing strings obtained from makefiles
   *         and stored in global structures.
   */

diff -c -r cscope-15.9/src/find.c cscope-15.9-fixed/src/find.c
*** cscope-15.9/src/find.c    2018-03-19 22:37:27.000000000 +0100
--- cscope-15.9-fixed/src/find.c    2022-05-01 12:57:59.000000000 +0200
***************
*** 48,53 ****
--- 48,55 ----
  #endif
  #include <regex.h>

+ #define BUFFER_SIZE 8192
+
  /* most of these functions have been optimized so their innermost loops have
   * only one test for the desired character by putting the char and
   * an end-of-block marker (\0) at the end of the disk block buffer.
***************
*** 57,63 ****
   */

  char    *blockp;            /* pointer to current char in block */
! char    block[BUFSIZ + 2];        /* leave room for end-of-block mark */
  int    blocklen;            /* length of disk block read */
  char    blockmark;            /* mark character to be searched for */
  long    blocknumber;            /* block number */
--- 59,65 ----
   */

  char    *blockp;            /* pointer to current char in block */
! char    block[BUFFER_SIZE + 2];        /* leave room for end-of-block mark */
  int    blocklen;            /* length of disk block read */
  char    blockmark;            /* mark character to be searched for */
  long    blocknumber;            /* block number */
***************
*** 872,879 ****
          if (--cp < block) {
              retreat = YES;
              /* read the previous block */
!             (void) dbseek((blocknumber - 1) * BUFSIZ);
!             cp = block + (BUFSIZ - 1);
          }
      }
      blockp = cp;
--- 874,881 ----
          if (--cp < block) {
              retreat = YES;
              /* read the previous block */
!             (void) dbseek((blocknumber - 1) * BUFFER_SIZE);
!             cp = block + (BUFFER_SIZE - 1);
          }
      }
      blockp = cp;
***************
*** 975,981 ****
  }


! /* scan past the next occurence of this character in the cross-reference */
  char *
  scanpast(char c)
  {
--- 977,983 ----
  }


! /* scan past the next occurrence of this character in the cross-reference */
  char *
  scanpast(char c)
  {
***************
*** 1001,1007 ****
  read_block(void)
  {
      /* read the next block */
!     blocklen = read(symrefs, block, BUFSIZ);
      blockp = block;

      /* add the search character and end-of-block mark */
--- 1003,1009 ----
  read_block(void)
  {
      /* read the next block */
!     blocklen = read(symrefs, block, BUFFER_SIZE);
      blockp = block;

      /* add the search character and end-of-block mark */
***************
*** 1035,1041 ****

  /* find the functions called by this function */

! /* HBB 2000/05/05: for consitency of calling interface between the
   * different 'find...()' functions, this now returns a char pointer,
   * too. Implemented as a pointer to static storage containing 'y' or
   * 'n', for the boolean result values YES and NO */
--- 1037,1043 ----

  /* find the functions called by this function */

! /* HBB 2000/05/05: for consistency of calling interface between the
   * different 'find...()' functions, this now returns a char pointer,
   * too. Implemented as a pointer to static storage containing 'y' or
   * 'n', for the boolean result values YES and NO */
***************
*** 1044,1050 ****
  findcalledby(char *pattern)
  {
      char    file[PATHLEN + 1];    /* source file name */
!     static char found_caller = 'n'; /* seen calling function? */
      BOOL    macro = NO;

      if (invertedindex == YES) {
--- 1046,1052 ----
  findcalledby(char *pattern)
  {
      char    file[PATHLEN + 1];    /* source file name */
!     static char found_caller[2] = "n"; /* seen calling function? */
      BOOL    macro = NO;

      if (invertedindex == YES) {
***************
*** 1057,1068 ****
              case FCNDEF:
                  if (dbseek(p->lineoffset) != -1 &&
                      scanpast('\t') != NULL) {    /* skip def */
!                     found_caller = 'y';
                      findcalledbysub(srcfiles[p->fileindex], macro);
                  }
              }
          }
!         return(&found_caller);
      }
      /* find the function definition(s) */
      while (scanpast('\t') != NULL) {
--- 1059,1070 ----
              case FCNDEF:
                  if (dbseek(p->lineoffset) != -1 &&
                      scanpast('\t') != NULL) {    /* skip def */
!                     found_caller[0] = 'y';
                      findcalledbysub(srcfiles[p->fileindex], macro);
                  }
              }
          }
!         return(&found_caller[0]);
      }
      /* find the function definition(s) */
      while (scanpast('\t') != NULL) {
***************
*** 1072,1078 ****
              skiprefchar();    /* save file name */
              fetch_string_from_dbase(file, sizeof(file));
              if (*file == '\0') {    /* if end of symbols */
!                 return(&found_caller);
              }
              progress("Search", searchcount, nsrcfiles);
              break;
--- 1074,1080 ----
              skiprefchar();    /* save file name */
              fetch_string_from_dbase(file, sizeof(file));
              if (*file == '\0') {    /* if end of symbols */
!                 return(&found_caller[0]);
              }
              progress("Search", searchcount, nsrcfiles);
              break;
***************
*** 1087,1100 ****
          case FCNDEF:
              skiprefchar();    /* match name to pattern */
              if (match()) {
!                 found_caller = 'y';
                  findcalledbysub(file, macro);
              }
              break;
          }
      }

!     return (&found_caller);
  }

  /* find this term, which can be a regular expression */
--- 1089,1102 ----
          case FCNDEF:
              skiprefchar();    /* match name to pattern */
              if (match()) {
!                 found_caller[0] = 'y';
                  findcalledbysub(file, macro);
              }
              break;
          }
      }

!     return (&found_caller[0]);
  }

  /* find this term, which can be a regular expression */
***************
*** 1236,1243 ****
      long    n;
      int    rc = 0;

!     if ((n = offset / BUFSIZ) != blocknumber) {
!         if ((rc = lseek(symrefs, n * BUFSIZ, 0)) == -1) {
              myperror("Lseek failed");
              (void) sleep(3);
              return(rc);
--- 1238,1245 ----
      long    n;
      int    rc = 0;

!     if ((n = offset / BUFFER_SIZE) != blocknumber) {
!         if ((rc = lseek(symrefs, n * BUFFER_SIZE, 0)) == -1) {
              myperror("Lseek failed");
              (void) sleep(3);
              return(rc);
***************
*** 1245,1251 ****
          (void) read_block();
          blocknumber = n;
      }
!     blockp = block + offset % BUFSIZ;
      return(rc);
  }

--- 1247,1253 ----
          (void) read_block();
          blocknumber = n;
      }
!     blockp = block + offset % BUFFER_SIZE;
      return(rc);
  }

diff -c -r cscope-15.9/src/main.c cscope-15.9-fixed/src/main.c
*** cscope-15.9/src/main.c    2018-07-19 21:45:17.000000000 +0200
--- cscope-15.9-fixed/src/main.c    2022-05-01 08:03:54.000000000 +0200
***************
*** 884,890 ****
          break;
  #endif
      }
!     /* execute the commmand, updating the display if necessary */
      if (command(c) == YES) {
          display();
      }
--- 884,890 ----
          break;
  #endif
      }
!     /* execute the command, updating the display if necessary */
      if (command(c) == YES) {
          display();
      }

[Cscope-devel] [patch] fix crash with cscope-15.9 on macOS + typo fixes

[Dominique P. <dom...@gm...>]

Hi

cscope-15.9 (installed from homebrew) crashes on macOS (Monterey).
I then downloaded the source code to built it myself on macOS and
I could reproduce the crash. I then built cscope-15.9 with asan (address
sanitizer) and I see this:
```
=================================================================
==50182==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00010474cc81 at pc 0x00010d195718 bp 0x00030d14ae90 sp
0x00030d14a610
READ of size 2 at 0x00010474cc81 thread T0
    #0 0x10d195717 in printf_common(void*, char const*,
__va_list_tag*)+0x8e7
(libclang_rt.asan_osx_dynamic.dylib:x86_64+0x1f717)
    #1 0x10d1958f7 in wrap_vsnprintf+0x97
(libclang_rt.asan_osx_dynamic.dylib:x86_64+0x1f8f7)
    #2 0x10d19630d in wrap_snprintf+0x9d
(libclang_rt.asan_osx_dynamic.dylib:x86_64+0x2030d)
    #3 0x104676eb6 in search display.c:476
    #4 0x104662f9f in command command.c:522
    #5 0x104693b07 in main main.c:888
    #6 0x204a5e51d in start+0x1cd (dyld:x86_64+0x551d)

0x00010474cc81 is located 63 bytes to the left of global variable
'function' defined in 'find.c:1204:14' (0x10474ccc0) of size 251
0x00010474cc81 is located 0 bytes to the right of global variable
'found_caller' defined in 'find.c:1047:14' (0x10474cc80) of size 1
SUMMARY: AddressSanitizer: global-buffer-overflow
(libclang_rt.asan_osx_dynamic.dylib:x86_64+0x1f717) in
printf_common(void*, char const*, __va_list_tag*)+0x8e7
Shadow bytes around the buggy address:
  0x1000208e9940: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 01 f9 f9 f9 f9
  0x1000208e9950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000208e9960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000208e9970: 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x1000208e9980: 00 00 04 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
=>0x1000208e9990:[01]f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x1000208e99a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000208e99b0: 00 00 00 00 00 00 00 03 f9 f9 f9 f9 00 f9 f9 f9
  0x1000208e99c0: f9 f9 f9 f9 05 f9 f9 f9 f9 f9 f9 f9 07 f9 f9 f9
  0x1000208e99d0: f9 f9 f9 f9 07 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
  0x1000208e99e0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==50182==ABORTING
```

I can reproduce the crash at least with vim sources:
```
$ cd vim/src/testdir
$ cscope -bk -fcscope.out ../memfile_test.c
$ cscope -d
```
Then do:
```
Find functions called by this function: hash_mf_test
```
Type return and observe a crash.

In fact, I found this because Vim tests failed
when Vim is built with cscope support (as cscope
crashed on macOS):

```
$ cd vim/src/tests
$ make test_cscope
(observe that 2 tests fail)
```

I see that function `findcalledby(...)` in `cscope-15.9/src/find.c:1044`
returns a `char*` which contains a single character and it is not
'\0' terminated.  This causes a crash later when outputting it in
`display.c:476` with `snprintf(..., "Egrep %s in this pattern:%s", ...`

The proposed patch fixes that issue in `find.c` by making sure
the returned `char*` is '\0' terminated.

However, cscope still did not work on macOS for another
reason whereas it worked on Linux. Debugging the difference,
I saw that BUFSIZ is 1024 on macOS and 8192 on Linux and
somehow this causes cscope to not work on macOS.
I don't understand why  it causes it to break, but
replacing BUFSIZ (which is platform dependent)
with a '#define BUFFER_SIZE 8192' makes it work.
There may be another bug here lurking as I suppose
it should have worked even if the BUFSIZ was only 1024.
At least now I no longer see the asan error and vim
tests also pass with my proposed patch.

The proposed patch also fixes unrelated typos in
comments and in the cscope man pages.

Given that this fixes a crash, I hope a new cscope
release can be created soon.

I wanted to try with the latest code in CVS but
I was not able to download it from sourceforge.

Regards
Dominique

Re: [Cscope-devel] How to build cscope?

[Christopher S. <chr...@ya...>]

 Ah, thank you for pointing me to README.git file. I looked only at README and that pointed me to INSTALL, which didn't exist.
I honestly didn't think to look for a tarball to download - I figured git would be the only way to get the source code.
Thanks,
-svec

    On Monday, August 23, 2021, 02:27:48 PM EDT, Hans-Bernhard Bröker <hbb...@t-...> wrote:  
 
 Am 23.08.2021 um 17:15 schrieb Christopher Svec via Cscope-devel:

> Hi, I cloned cscope with "git clone
> https://git.code.sf.net/p/cscope/cscope" and now I'd like to know how
> to build a local copy on my Ubuntu machine.

You could normally just install the tool the Ubuntu package.  Or build 
from a tarball.  This is a very stable package; so there's really not 
much to be gained by installing from git.

> The README file says to look in the INSTALL file - but I don't see
> one. I also don't see a "configure" script that I might expect to
> run. How do I configure and build cscope from source?

Those are generated files, so they're not in git.  As explained in

    README.git.


_______________________________________________
Cscope-devel mailing list
Csc...@li...
https://lists.sourceforge.net/lists/listinfo/cscope-devel
  

Re: [Cscope-devel] How to build cscope?

[Hans-Bernhard B. <HBB...@t-...>]

Am 23.08.2021 um 17:15 schrieb Christopher Svec via Cscope-devel:

> Hi, I cloned cscope with "git clone
> https://git.code.sf.net/p/cscope/cscope" and now I'd like to know how
> to build a local copy on my Ubuntu machine.

You could normally just install the tool the Ubuntu package.  Or build 
from a tarball.  This is a very stable package; so there's really not 
much to be gained by installing from git.

> The README file says to look in the INSTALL file - but I don't see
> one. I also don't see a "configure" script that I might expect to
> run. How do I configure and build cscope from source?

Those are generated files, so they're not in git.  As explained in

	README.git.

[Cscope-devel] How to build cscope?

[Christopher S. <chr...@ya...>]

Hi,
I cloned cscope with "git clone https://git.code.sf.net/p/cscope/cscope" and now I'd like to know how to build a local copy on my Ubuntu machine.

The README file says to look in the INSTALL file - but I don't see one. I also don't see a "configure" script that I might expect to run.
How do I configure and build cscope from source?
Thanks!
-svec

Re: [Cscope-devel] a small issue in contrib/ocs and a fix

[Temp V. <tem...@gm...>]

Yes, this is probably covscan running shellcheck as a part of a check.

Thank you, Hans!

Best regards,
Vladis

ср, 28 апр. 2021 г. в 22:27, Hans-Bernhard Bröker <HBB...@t-...>:

> Am 28.04.2021 um 01:46 schrieb Temp Valve:
>
> > It looks like the recent commit [bb7f25fa] "contrib/ocs: Fix bashims
> > (Closes: #480591)" has introduced a small issue, at least covscan
> > reports the following:
> Hmm... that seems to be shellcheck, not covscan.  And that reports a
> whole lot more than this single warning.
>
>
> I'll see which of those I'll fix.
>
> Thanks for the report
>
>

Re: [Cscope-devel] a small issue in contrib/ocs and a fix

[Hans-Bernhard B. <HBB...@t-...>]

Am 28.04.2021 um 01:46 schrieb Temp Valve:

> It looks like the recent commit [bb7f25fa] "contrib/ocs: Fix bashims 
> (Closes: #480591)" has introduced a small issue, at least covscan
> reports the following:
Hmm... that seems to be shellcheck, not covscan.  And that reports a 
whole lot more than this single warning.


I'll see which of those I'll fix.

Thanks for the report

[Cscope-devel] a small issue in contrib/ocs and a fix

[Temp V. <tem...@gm...>]

Hello,

It looks like the recent commit [bb7f25fa] "contrib/ocs: Fix bashims
(Closes: #480591)"
has introduced a small issue, at least covscan reports the following:

1. /usr/bin/ocs:213:13: warning[SC2039]: In POSIX sh, printf -I is
undefined.
#    for i in `cat ${theInc}`
#    do
#        printf "-I $i "
#    done

Indeed (standard bash-5.0.17):

$ printf "-I test "
bash: printf: -I: invalid option
printf: usage: printf [-v var] format [arguments]

but this works fine:

$ printf -- "-I test "
-I test <no lf>

I believe, a small patch like this would fix this small issue:

--- contrib/ocs.old        2021-04-28 00:21:22.118029152 +0200
+++ contrib/ocs        2021-04-28 00:21:42.417089321 +0200
@@ -210,5 +210,5 @@
         for i in `cat ${theInc}`
         do
-            printf "-I $i "
+            printf -- "-I $i "
         done
     fi

Best regards,
Vladis

Re: [Cscope-devel] -L0 works but -L3 shows nothing

[Timur T. <ti...@ta...>]

On 7/7/20 5:50 PM, Hans-Bernhard Bröker wrote:
> Which in turn means that there are almost certainly aspects of the way 
> this codebase expresses function definitions that make them 
> unrecognizable to the cscope parser.  If there are, e.g., any kind of 
> macros involved in that, they most likely cannot be recognized.
> 
> All that text in the "Notices" section of the manual, on the 
> recognizable pattern for a function definition, is there for a reason...

Thank you.  It took me a while, but I figured out the problem.  cscope 
doesn't like it when the left parenthesis after the function declaration 
is on a different line.  So this works:

int bla(
	int x
)
{
}

but this doesn't:

int bla
(
	int x
)
{
}

I can use uncrustify to reformat the C files so that they'll make cscope 
happy.

Re: [Cscope-devel] -L0 works but -L3 shows nothing

[Hans-Bernhard B. <HBB...@t-...>]

Am 07.07.2020 um 22:33 schrieb Timur Tabi:

> I have a large project that has a somewhat quirky coding style (lots of 
> questionable macros) and I'm trying to get cscope to give me a list of 
> functions that call another function, X.

It's almost certainly those quirks that prevent cscope from actually 
parsing that source code correctly.

> cscope is obviously able to parse the C code correctly.

No, it didn't parse it correctly, and that's obvious from the L0 output:

>> kernel/pmgr/nv/pwrchannel_pstate_est_lut.c <global> 57 status = constructPwrChannel(pGpu, ppBoardObj, size, pArgs);

The clue is here -----------------------------^^^^^^^^

In that position you're supposed to see the name of the function this 
reference was found in.  I.e. the calling function.  There is none, 
which means cscope did not believe this line to be inside any function 
body; it found it at <global> scope.

Which in turn means that there are almost certainly aspects of the way 
this codebase expresses function definitions that make them 
unrecognizable to the cscope parser.  If there are, e.g., any kind of 
macros involved in that, they most likely cannot be recognized.

All that text in the "Notices" section of the manual, on the 
recognizable pattern for a function definition, is there for a reason...

[Cscope-devel] -L0 works but -L3 shows nothing

[Timur T. <ti...@ta...>]

I have a large project that has a somewhat quirky coding style (lots of 
questionable macros) and I'm trying to get cscope to give me a list of 
functions that call another function, X.

My understanding is that that is what the -L3 option is for.  However, 
when I run -L3 on any function of interest, cscope reports no results. 
-L0, however, does list everything.

So for now, my project parses the output of -L0 and attempts to ignore 
references that do not apply.  However, I don't understand why -L3 isn't 
working.  cscope is obviously able to parse the C code correctly.

Here's an example:

> $ cscope  -d   -L0 constructPwrChannel
> kernel/inc/pmgr/pwrchannel.h <global> 149 BoardObjConstruct constructPwrChannel;
> kernel/pmgr/nv/pwrchannel.c <global> 136 constructPwrChannel
> kernel/pmgr/nv/pwrchannel.c <global> 774 return constructPwrChannel(pGpu, ppBoardObj, size, pArgs);
> kernel/pmgr/nv/pwrchannel_pstate_est_lut.c <global> 57 status = constructPwrChannel(pGpu, ppBoardObj, size, pArgs);
> kernel/pmgr/nv/pwrchannel_sensor.c <global> 56 status = constructPwrChannel(pGpu, ppBoardObj, size, pArgs);
> kernel/pmgr/nv/pwrchannel_sum.c <global> 60 status = constructPwrChannel(pGpu, ppBoardObj, size, pArgs);

In this case, -L3 should return the last four lines, but I get nothing 
instead:

$ cscope  -vd   -L3 constructPwrChannel
> Search 7434 of 11098
$

Re: [Cscope-devel] cscope find the exact struct definition in linux kernel

[Hans-Bernhard B. <HBB...@t-...>]

Am 01.08.2019 um 05:14 schrieb 袁建鹏:

> : cs find g platform_device
> 
> But the result contains lots of other things. like:
> 
> variable named platform_device
> declaration of struct platform_device

These are perfectly valid results of the search you ran: "find global
definition".  If you find truly large numbers of the same identifier in
such a search, that might be an indication of the source code being in
bad shape.

> arguments whose type is struct platform device

This would not normally count as a valid result for this search.  But
here you're running into the known (and documented) limitation of the
cscope parser in case of function pointers, or generally any function
argument lists with more than the one pair of parentheses.  The primary
effect of that limitation is to blur the distinction between global and
local definitions, leading to spurious "global" definitions that are
actually local.

> Can I let cscope find only the exact definition of struct platform_device. 

In a nutshell: no.  That's not what cscope is meant to do.

[Cscope-devel] cscope find the exact struct definition in linux kernel

[袁建鹏 <yua...@16...>]

Hi

I use cscope in vim. I want to find the definition of struct platform_device. 

I try
: cs find g platform_device

But the result contains lots of other things. like:

variable named platform_device
declaration of struct platform_device
arguments whose type is struct platform device

such as
int (*setup)(struct platform_device *, struct legacy_probe *probe,
struct platform_device;

the definition is also included in the result, but it't very difficult to find it because the output is too long.
Can I let cscope find only the exact definition of struct platform_device. 

[Cscope-devel] Repository move required.

[Hans-Bernhard B. <HBB...@t-...>]

Hello everyone,

I'll assume most of you have heard that SF.net is about to discontinue 
CVS service next month.  In preparing for this, I propose we change over 
to a git repository (still at SF.net).  SVN would be available, too, but 
we might as well make the leap to what everybody is using these days...

One key element for such a move is a mapping of SF.net user names to 
mail addresses and time zone preferences.  An autogenerated first draft 
would be this:

horman = Neil Horman <nh...@tu...>
uzi = Joshua Uziel <uz...@li...>
darrylo = Darrylo Okahata <da...@us...>
hops1 = Mike Hopkirk <ho...@sc...>
petr = Petr Sorfa <pe...@us...>
cvs-fast-export = cvs-fast-export <cvs-fast-export>
broeker = Hans-Bernhard Broeker <br...@us...> 
Europe/Berlin

Anyone wanting this changed should speak up soon-ish.

[Cscope-devel] Clearing backlog of reported bugs?

[Alex <ale...@gm...>]

Dear cscope devs,

I'm a cscope user who was just browsing your project page and noticed a
very long backlog of bug reports, some more than 10 years old. At first I
thought the project may have been unmaintained for years, but it seems
that's not the case.

Are you interested in accepting patches which fix some of those bugs? If
so, would you accept a contribution of a test suite first (to help prevent
regressions when working on the bugs)?

Thank you,
Alex Dowad

[Cscope-devel] cscope-15.8b released

[Hans-Bernhard B. <HBB...@t-...>]

Hello everybody,

I decided that the bug fix in egrep.y needed to be spread out more, so I 
made a new release of cscope today.  It's tagged v15_8b in CVS, and the 
release tar ball is out on SourceForge.net.

Hans-Bernhard Broeker