On Fri, Oct 4, 2013 at 3:01 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> i'm also working on a repro in a 32-bit vm in parallel. "In theory" a
> malloc failure is not possible because fossil_malloc() aborts on alloc
> error, but we do have a few places which use malloc()/free() instead of
> fossil_{malloc,free}().
>
Also work on 32-bit for me. Normally one is happy about success, but this
time not.
i'm at a loss.
The problem is definitely the empty P-card (meaning that the manifest looks
like it has no parent version, which is just wrong), but i cannot say why
that happens. As Jan hypothesized, this sounds almost like a memory misuse,
but that seems to have been ruled out. It's too specific of a problem (and
reproducible on Ron's end) to be generic memory corrupt.
Thankfully, the verify-before-commit logic catches this and keeps this from
being immortalized in the repo.
@Ron: which fossil version are you on, and what platform?
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
