On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > > > On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Yakov Lerner wrote:
> > > > >
> > > > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote:
> > > > > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
> > > > > > > > > involving tags break, including the help system. Typing :h,
> > > > > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in
an
> > > > > > > > > infinite loop.
> > > > >
> > > > > [...]
> > > > >
> > > > > > > Can you find out where in the code this happens?
> > > > > > >
> > > > > > > I suspect the 64 bit library functions work different from the
"normal"
> > > > > > > functions. Perhaps fgets(), since that's what is being used to
read the
> > > > > > > tags file.
> > > > > >
> > > > > > In situation where fgets() returns NULL, find_tags() enters
> > > > > > infinite loop as follows.
> > > > >
> > > > > Sorry, this doesn't show me where the loop actually is. Please compile
> > > > > without the optimizer, otherwise code reordering confuses the
debugger.
> > > > >
> > > > > At least tell us if Vim hangs in tag_fgets() or in find_tags().
> > > >
> > > > The loop is is inside find_tags(), and it procees around following line
> > > > numbers:
> > > > 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566
> > > > 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625
> > > > and infinite loop repeats. Look at this:
> > > > gdb> print print search_info.curr_offset
> > > > $2 = 5258708303049
> > >
> > > I cannot guess where this loop first gets beyond end of file
> > > (filesize=2506), but once it gets beyond, we are missing check that
> > > search_info.*offset''s are beyond end of file ?
> > > Maybe add such check somewhere ? I don't know where to add the check.
> > >
> > > Yakov
> >
> > It seems I found the culprint. It is line 1651,
> > search_info.match_offset = ftell(fp);
> >
> > (gdb) p ftell(fp)
> > $11 = 2506
> > (gdb) n
> > 1652 search_info.curr_offset =
> > search_info.curr_offset_used;
> > (gdb) p search_info.curr_offset
> > $12 = 5258708302025
> > (gdb)
>
> Ok, this must be gcc bug. It bites even without optimization.
> Rewriting lines 'search_info.curr_offset = ftell(fp)' fixes the problem
> if I rewrite them into this:
> long ltmp;
> ltmp = ftell(fp);
> search_info.curr_offset = ltmp;
>
> NB that ftell() returns long. Type of search_info.curr_offset is long
> long when -D_FILE_OFFSET_BITS=64. Simpe asignment
> search_info.curr_offset = ftell(fp)
> puts trash into lhs. ftell(fp) by itself returns correct number.
> this is gcc 3.4.2 Fedora3
Surprisingly, changing ftell() to ftello() does not change anything.
Casting ftell() to (off_t) doesn't change anything.
Funnily, casting ftell to (long) makes the problem go away
(as it ftell does not already return long, it does):
1628 search_info.curr_offset = (long)ftell(fp);
1644 search_info.curr_offset = (long)ftell(fp);
1651 search_info.match_offset = (long)ftell(fp);
New developments:
It looks like -D_FILE_OFFSET_BITS=64 alone is wrong because
it's not complete. Correct build settings are:
gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
This makes problem go away without any changes in the sources.
Haakon: can you check that adding these solves the problem on you rmachine ?
Yakov
3. Thou shalt not use Google as a verb.
http://www.thechurchofgoogle.org/Scripture/10_Commandments.html
