Re: global got SIGABRT when analyzing long line

[Hideki IWAMOTO]

Hi.

This bug was reported 4 years ago, and already listed in Known bugs.
  http://www.gnu.org/software/global/bugs.html

I have fixed the bug in the repository.
  
http://cvs.savannah.gnu.org/viewcvs/global/libutil/pool.c?cvsroot=global&r1=1.6&r2=1.7

Thank you for the report.


On Fri, 29 Jan 2016 15:08:03 +0900 (JST)
KAICHO <address@hidden> wrote:

> Hi,
> 
> This is a bug reaport that I got SIGABRT during running global.
> This can be reproduced with the latest global-6.5.2.
> 
> 
> What is your environment (OS)?
> OS: CentOS 5.11, 6.7(Linux x86_64)
> 
> Which version of GLOBAL are you using?
> GNU GLOBAL: 6.5.2
> 
> What did you do? (command line)
> 1. create 2 files, both have only 1 line:
> ??? a:c??? int abc() {};
> ??? a.html <a name="name">link</a>aaaaaaaaaaaaa....
> ??????? (continues 5000 'a's without '\n')
> 2. run gtags
> ??? # gtags --gtagsconf /etc/gtags.conf --gtagslabel=exuberant-ctags
> ??? (which tags .c with default parser and .html with exuberant-ctags)
> 3. run global
> ??? # global -x ".*"
> 
> What did you expect from it?
> global shows the labels.
> 
> What was occurred? (as is)
> global displays:
> === 8< ======
> abc?? 1 a.c???? int abc() {}
> name? 1 a.html? <a name="name">link</a>aaaaa(snip 5000 'a's)
> Aborted (core dumped)
> === 8< ======
> 
> 
> gdb for the core file shows that it aborted in obstack_free().
> 
> # gdb /usr/bin/global core.24954
> (snip)
> (gdb) where
> (snip)
> #1? 0x0000003946c31a70 in abort () at abort.c
> #2? 0x0000003946c7837b in obstack_free () at obstack.c
> #3? 0x00000000004166ca in gtags_next () at gtagsop.c
> #4? 0x0000000000402ac1 in search () at global.c
> #5? 0x0000000000402bb2 in tagsearch () at global.c
> #6? 0x0000000000405b6e in main () at global.c
> (gdb)
> 
> Actually, I found two interesting workarounds:
> A. reduce a line width less than 4000 chars in a.html(by inserting '\n')
> B. rename the function name from abc() to xbc() in a.c
> 
> This seems to be caused by the shortage of the chunk_size of
> obstack which is initialized to 4096-extra, since this can
> roughly be avoided by replacing "obstack_init(&pool->obstack);"
> in pool_open() in libutil/pool.c to:
> 
> ?? _obstack_begin ((&pool->obstack), 8192, 0,
> ?????????????? (void *(*) (long)) obstack_chunk_alloc,
> ?????????????? (void (*) (void *)) obstack_chunk_free);
> ????????? pool->first_object = obstack_alloc(&pool->obstack, 1);
> 
> to increase the default chunk_size.
> However I know this is not good fix, and I can not explain
> why the workaround B is available...
> 
> It is better that global can handle vaious line width.
> But It would be O.K. global has a restriction that line width
> should be 4000 chars. If so, please print a detailed
> error message which indicates the reason why global fails
> at the case.
> 
> Regards,
> KAICHO
> 
> 
> _______________________________________________
> Bug-global mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-global

-- 
Hideki IWAMOTO <address@hidden>