REBOL3 tracker
  0.9.12 beta
Ticket #0002214 User: anonymous

Project:

Previous Next
rss
TypeBug Statussubmitted Date2-Apr-2015 14:56
Versionr3 master CategoryParse Submitted byfork
PlatformAll Severitycrash Priorityhigh

Summary Modifying running PARSE rule leads to execution beyond rule TAIL, possible crash
Description In the implementation of PARSE as written, rules blocks are processed via a pointer into the series data block. This pointer is incremented until an end-of-series marker token is reached in the data area:

https://github.com/rebol/rebol/blob/25033f897b2bd466068d7663563cd3ff64740b94/src/core/u-parse.c#L668

Shrinking the size of a series does not currently reclaim or reallocate extra memory (I don't think), so the following won't crash...it continues in the now-past-tail data block until it hits END!. However, it shows a bit of "surprising" (invalid, I'd say) behavior:

>> parse "abcde" rule: ["a" "b" (clear rule) "c" "d" "e"]
== true

However, *growing* a rule can lead to an Expand_Block, which can mean the underlying memory block of the rule series can be reallocated...hence freed and allocated at a new location. This leads to an invalid situation and may crash.

(Note: Due to Rebol attempting to do its own memory pooling instead of trusting the allocator to take care of it, there is not an actual call to realloc(). Hence diagnosis tools like Valgrind cannot alert you to this situation--or others like it. It takes a rare condition to actually crash.)

The DO evaluation loop is protected against this kind of situation by re-fetching the series data pointer each time...also noticing changes in length. PARSE could be rewritten to do the same. How this would impact performance is unknown.

A bigger question is probably what semantics are intended:

http://stackoverflow.com/questions/29399510/what-are-the-rules-about-self-modifying-parse-rules-in-rebol-red

There seem to be several cases where "if you know what you're doing" then being allowed to modify the rule can be a powerful tool. As Rebol is permissive in general, then if the possibility for crashing is fixed...it may be good to continue allowing it. Can't crash, though.
Example code

			

Assigned ton/a Fixed in- Last Update7-Apr-2015 01:23


Comments
(0004635)
abolka
7-Apr-2015 01:23

Good analysis, Fork! Re the "what are the rules about self-modifying parse rules" question, the following shows an obvious inconsistency:

>> parse "abcd" rule: ["ab" (clear rule) "cd"]
== true ;; Rule self-modification is NOT respected.

>> parse "abcd" rule: ["ab" (remove back tail rule) "cd"]
== false ;; Rule self-modification IS respected.

I think the more prevalent expectation is that self-modification of rules works. Either way, the above two examples should either both fail or both succeed.

Date User Field Action Change
7-Apr-2015 01:23 abolka Comment : 0004635 Added -
2-Apr-2015 14:57 Fork Description Modified -
2-Apr-2015 14:56 Fork Ticket Added -