Bug 25302 - Mismatching fstat() function calls in gdb_bfd_open() and cache_bstat()
Summary: Mismatching fstat() function calls in gdb_bfd_open() and cache_bstat()
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: win32 (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 10.1
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-20 19:05 UTC by Hannes Domani
Modified: 2020-09-08 16:49 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2020-01-14 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Hannes Domani 2019-12-20 19:05:58 UTC 
The fstat() call in cache_bstat() (cache.c) uses the "normal" function of the CRT,
but the one in gdb_bfd_open() (gdb_bfd.c) uses the redefined variant rpl_fstat() of gnulib.

But both of them return different values in st_mtime (timezone difference?), which makes htab_find_with_hash() then fail to find the cached value in gdb_bfd_cache.

It's not even possible to start a simple hello world application, gdb always crashes.

As a workaround I did push_macro/undef both fstat and stat before gdb_bfd_open(), und pop_macro afterwards.
This works fine for me so far, but there are probably other fstat() calls which might have a similar problem, and also the same might be true for stat() calls.


It probably started with commit c0c3707ff46ccfb78ea175dd42d628d8c90dca8b (Update Gnulib to the latest git version).
Comment 1 Tom Tromey 2020-01-14 18:17:27 UTC 
I'm testing a patch.
Comment 3 Joel Brobecker 2020-06-15 23:29:45 UTC 
adding target milestone (10.1), since this is a pretty significant problem.
Comment 4 Tom Tromey 2020-09-08 16:49:47 UTC 
The commit messages didn't show up here, even though
the PR was mentioned in them.  Anyway, I think this is fixed now.