This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need help debugging likely g++ preprocessor bug



On 11/23/2017 07:33 AM, Jonathan Wakely wrote:
> On 22 Nov 2017 11:41 p.m., "Mike Gulick" wrote:
>> I have tried looking at this in gdb for quite a few days, but I haven't found
>> any definitive answers.  The one possible clue is that I have noticed that the
>> source_location numbers in use are close to LINE_MAP_MAX_LOCATION_WITH_COLS
>> (0x60000000).  E.g. I am seeing source locations in the debugger of 1610043911
>> (0x5FF75207).  In other examples, I am seeing source locations just over this
>> limit.
>>
>> I would greatly appreciate suggestions for debugging this issue further.  I have
>> been looking at it for over a week and am hitting a bit of a wall.
> 
> Are there any odd characters in the headers, specifically
> carriage-returns (i.e. DOS line-endings) or maybe some Unicode space
> characters that aren't whitespace in ASCII?
> 

There may be, but unfortunately this doesn't look to be relevant.  See my next
comment.

> It's certainly possible you've hit some edge case and the linemap is
> being corrupted. If you add the -v option to your gcc commands you'll
> see the cc1plus command that's being run, and then you can run that
> command under valgrind to see if there are any errors shown.
> Alternatively, rebuild GCC after configuring it with the
> --enable-checking=valgrind option, which will build GCC with valgrind
> debugging built-in. That build of GCC will run very slowly, but using
> it on your source code will check for any uninitialized reads/writes
> or other memory bugs that could be the cause of what you're seeing.
> 

Thanks for the suggestion.  I did initially try creating a valgrind build of gcc
7.2 and ran it under valgrind as documented in the gcc wiki, but it did not
report any issues.

I still haven't had any success trying to track down the source of the issue in
the debugger.  However I did have success in creating a simple reproduction
case.  This bug *is* dependent on crossing over LINE_MAP_MAX_LOCATION_WITH_COLS,
so the reproducer includes a simple gcc plugin that sets the line map's
highest_location field before the preprocessor runs.  I have created bug 83173
and have attached the reproduction source code to that bug.

-Mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]