bug-global
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segmentation fault in version 6.2.3


From: Shigio YAMAGUCHI
Subject: Re: Segmentation fault in version 6.2.3
Date: Wed, 30 May 2012 15:48:35 +0900

Dear Sir or Madam

Would you please try the following patch?
This bug will be fixed, I believe.

I had overlooked the big bug.
I will release a bug fix version (global-6.2.4) soon.

Thank you for the report.

Best Regards

Index: libutil/find.c
===================================================================
RCS file: /sources/global/global/libutil/find.c,v
retrieving revision 1.89
diff -c -r1.89 find.c
*** libutil/find.c      17 May 2012 11:43:05 -0000      1.89
--- libutil/find.c      30 May 2012 06:29:58 -0000
***************
*** 753,759 ****
                 * A blank at the head of path means
                 * other than source file.
                 */
!               if (regexec(suff, path, 0, 0, 0) != 0)
                        *--path = ' ';
                return path;
        }
--- 753,759 ----
                 * A blank at the head of path means
                 * other than source file.
                 */
!               if (!issourcefile(path))
                        *--path = ' ';
                return path;
        }

> Dear Gnu Global authors:
>          I'm a vimer and enjoying with gnu-global. So thanks for your great=
>  software.
>          But when I update Global from 6.2.2. to 6.2.3 I've encountered a "=
> Segmentation fault":
> 
> 1.       what is your environment (OS)?:
> linux 2.6.31, vim
> 
> 2.       Which version of GLOBAL are you using?
> 
> 6.2.3
> 
> 3.       What did you do? (command line)
> 
> cd $(proj_root) (only contain main.c)
> 
> cat `pwd`/main.c > file.list
> 
> gtags -f file.list
> 
> 4.       What did you expect from it?
> 
> Generate tags correctly
> 
> 5.       What was occurred? (as is)
> 
> Segmentation fault
> 
>          After watching the codes, I find that the fault is caused by the r=
> egex.c line 5759 in function regexec(). The line is:
>                             boolean want_reg_info =3D !preg->no_sub && nmat=
> ch > 0;
>          And the program fault because the preg is NULL. The regexex() is c=
> alled by the function find_read_filelist() in find.c line 756. The code cal=
> ling the regexec() was:
>                             If (regexec(suff, path, 0, 0, 0) !=3D 0) ...
>          Here the suff is null, so the program fault. And the suff was a st=
> atic regext point in the file find.c. It can only be inited in the function=
>  issourcefile().
>          So, I think the program fault because function issourcefile() is n=
> ot called by somebody if I execute the commands above. But I don't know whe=
> re and when to call this function, what's the meaning of this function. So =
> I don't know how to resolve this bug. Could you please help me?
> 
> Best Regards
--
Shigio YAMAGUCHI <address@hidden>
PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3



reply via email to

[Prev in Thread] Current Thread [Next in Thread]