-
Notifications
You must be signed in to change notification settings - Fork 365
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
Condition((vfc->vfp_nxt) != 0) not true in vbf_stp_fetchbody() #2645
Comments
possible clues:
|
nigoroll
added a commit
that referenced
this issue
Apr 11, 2018
Ref #2645 but cannot be the cause because workspace is just not overflowed
If the workspace was overflowed, I would believe to understand this issue, but as it's not, I don't |
Has happened again. The panic output is almost identical, but this time the workspace was exactly full yet still not overflown (previously, we had 8 bytes left).
|
for completeness, here's the same panic reproduced on acd9cab with vtc - but with the overflowed ws.
|
nigoroll
added a commit
that referenced
this issue
Apr 19, 2018
nigoroll
added a commit
that referenced
this issue
Apr 19, 2018
issue a membar to ensure that the overflow marker is written before a failing WS allocation returns and is thus visible from a different context. pan_ic() already has an implicit membar via the mutex lock. Ref #2645
nigoroll
added a commit
that referenced
this issue
Apr 20, 2018
As WS_Reset() clears the overflow marker, the correct order for resetting and marking an overflow is WS_Reset(); WS_MarkOverflow(); Fixes the last seemingly obscure bit of #2645
dridi
pushed a commit
to dridi/varnish-cache
that referenced
this issue
Jun 20, 2018
Ref varnishcache#2645 but cannot be the cause because workspace is just not overflowed
dridi
pushed a commit
to dridi/varnish-cache
that referenced
this issue
Jun 20, 2018
dridi
pushed a commit
to dridi/varnish-cache
that referenced
this issue
Jun 20, 2018
As WS_Reset() clears the overflow marker, the correct order for resetting and marking an overflow is WS_Reset(); WS_MarkOverflow(); Fixes the last seemingly obscure bit of varnishcache#2645
dmatetelki
pushed a commit
to dmatetelki/varnish-cache
that referenced
this issue
Mar 14, 2019
Ref varnishcache#2645 but cannot be the cause because workspace is just not overflowed
dmatetelki
pushed a commit
to dmatetelki/varnish-cache
that referenced
this issue
Mar 14, 2019
dmatetelki
pushed a commit
to dmatetelki/varnish-cache
that referenced
this issue
Mar 14, 2019
issue a membar to ensure that the overflow marker is written before a failing WS allocation returns and is thus visible from a different context. pan_ic() already has an implicit membar via the mutex lock. Ref varnishcache#2645
dmatetelki
pushed a commit
to dmatetelki/varnish-cache
that referenced
this issue
Mar 14, 2019
As WS_Reset() clears the overflow marker, the correct order for resetting and marking an overflow is WS_Reset(); WS_MarkOverflow(); Fixes the last seemingly obscure bit of varnishcache#2645
dmatetelki
pushed a commit
to dmatetelki/varnish-cache
that referenced
this issue
Mar 14, 2019
No need to remain paranoid when the actual root case is dead simple (see previous commit) This reverts commit f5ce551. Ref: varnishcache#2645
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: