New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Null pointer in S_set_haseval #16016
Comments
From @Mipu94File attached bellow was found by hongfuzz that triggered a crash in some info about this bug on GDB and ASAN. GDB-peda : Program received signal SIGSEGV, Segmentation fault. ASAN : ASAN:DEADLYSIGNAL==46788==ERROR: AddressSanitizer: SEGV on unknown address AddressSanitizer can not provide additional info. -- |
From @iabynOn Tue, Jun 13, 2017 at 08:27:12AM -0700, sung wrote:
The file doesn't appear to have been attached, or has been lost by the -- |
The RT System itself - Status changed from 'new' to 'open' |
From @Mipu94May be i forgot attach file. I resend you that poc was attached bellow. 2017-06-14 15:36 GMT+07:00 Dave Mitchell via RT <
-- |
From @TuxOn Wed, 14 Jun 2017 18:00:38 +0700, Ta Sung <tadinhsung@gmail.com>
This is perl 5, version 26, subversion 0 (v5.26.0) built for x86_64-linux-thread-multi-ld Program received signal SIGSEGV, Segmentation fault. This is perl 5, version 27, subversion 0 (v5.27.0) built for x86_64-linux Program received signal SIGSEGV, Segmentation fault. -- |
From @iabynOn Wed, Jun 14, 2017 at 01:51:15PM +0200, H.Merijn Brand wrote:
This is code containing lots of nested closures and formats, and which has I think this is another example of why we should instead just stop parsing In any case I don't think it counts as a security issue. -- |
From @demerphqOn 24 Jun 2017 16:01, "Dave Mitchell" <davem@iabyn.com> wrote: On Wed, Jun 14, 2017 at 01:51:15PM +0200, H.Merijn Brand wrote:
This is code containing lots of nested closures and formats, and which has I think this is another example of why we should instead just stop parsing What are the trade offs involved in this? Yves |
From @iabynOn Mon, Jun 26, 2017 at 09:39:54AM +0200, demerphq wrote:
There was, IIRC, a p5p thread about this recently, but I can't find it It means only the first compilation error gets reported to the user, Whether this is good or bad depends on your viewpoint. The cases where It's possible that the first error message is misleading, and could be It's possible that the second and subsequent error messages are Personally I hardly ever check beyond the first error message. Its *very* hard to keep compilation going after an error without leaks, -- |
From @demerphqHi On 26 Jun 2017 10:21, "Dave Mitchell" <davem@iabyn.com> wrote: On Mon, Jun 26, 2017 at 09:39:54AM +0200, demerphq wrote:
There was, IIRC, a p5p thread about this recently, but I can't find it Thanks for the summary. It means only the first compilation error gets reported to the user, Whether this is good or bad depends on your viewpoint. The cases where It's possible that the first error message is misleading, and could be It's possible that the second and subsequent error messages are Personally I hardly ever check beyond the first error message. Its *very* hard to keep compilation going after an error without leaks, So the cost is high and the benefit unclear and possibly even negative. Is it easy to build a perl that does not continue to see how that would Also would it be possible to treat strict-only errors differently? The only If we are talking about errors/panics that would apply even without strict Cheers, |
From @jhi
I have blissfully manaaged to forget most all of I ever learned of
|
From @tonycozOn Sat, 24 Jun 2017 07:01:54 -0700, davem wrote:
Moved to the public queue. Wasn't the the cause of some similar issues that failed sub-parses didn't restore the shift-reduce parser stack to the state before the sub-parse? The parser would shift in new tokens, reduce based on tokens from the sub-parse and use inconsisten PL_parser state (and crash). Tony |
It still fails under valgrind in 5.28 so I don't think bb4e4c3 fixed it - the valgrind backtrace is the same in 5.26. It completes "successfully" (reporting the syntax error) in 5.30. |
Migrated from rt.perl.org#131568 (status was 'open')
Searchable as RT131568$
The text was updated successfully, but these errors were encountered: