https://sourceware.org/bugzilla/show_bug.cgi?id=30951
yuxuan He <1157401338 at qq dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |1157401338 at qq dot com --- Comment #3 from yuxuan He <1157401338 at qq dot com> --- (In reply to Nick Clifton from comment #2) > Hi 时宇羽然 , > > Thank you for reporting this problem. Your analysis is basically correct > and so I have gone ahead and applied a small patch to add a check for > YY_CURRENT_BUFFER being NULL. > > The only problem I had with your analysis is that is shows the contents > of the bfin-lex.c file, which is not the one that is built from the > ld/ldlex.l > input file. I was concerned that there might have been some differences > between bfin-lex.c and ldlex.c, differences that affected this problem. > But, it turns out that as far as defining YY_CURRENT_BUFFER they are both > the same. > > Cheers > Nick (In reply to 时宇羽然 from comment #0) > Created attachment 15159 [details] > the detailed information of the bug > > Hi, I found a null pointer dereference bug in the source code of binutils, > and I have shown the execution sequence below. This bug exists in the file > /ld/ldlex.l. The white text illustrates the steps that generate the bug. > The return value of YY_CURRENT_BUFFER can be null, then it dereferenced at > line 659 without checking if it is null.The detailed instrunctions are in > the attachment. (In reply to Nick Clifton from comment #2) > Hi 时宇羽然 , > > Thank you for reporting this problem. Your analysis is basically correct > and so I have gone ahead and applied a small patch to add a check for > YY_CURRENT_BUFFER being NULL. > > The only problem I had with your analysis is that is shows the contents > of the bfin-lex.c file, which is not the one that is built from the > ld/ldlex.l > input file. I was concerned that there might have been some differences > between bfin-lex.c and ldlex.c, differences that affected this problem. > But, it turns out that as far as defining YY_CURRENT_BUFFER they are both > the same. > > Cheers > Nick you are right, our analysis do not tell where the macro is defined, because macro is inlined during preprocecing of compile, we actually find the define via ide l tool, so the file we report may be uncorrect, sorry for that, but based on the analysis results, the actual macro definition should not differ significantly, as you said -- You are receiving this mail because: You are on the CC list for the bug.