After loading an existing state in a fresh session, I find that previously defined calls to C functions (saved in the state) crash the session if (and only if) the foreign call was called in an earlier session before the state was saved. I can supply an example if necessary.
After investigating, it is actually malloc that is failing in the calls. Surprisingly, the very first malloc in the session finds an existing address. As freeList is emptied by PolyML.onEntry presumably freeList is being restored by loadState. Does that sound like an issue? I would expect that the freeList state is untouched by loadState.
Phil
Phil,
On 19/01/2016 18:38, Phil Clayton wrote:
After loading an existing state in a fresh session, I find that previously defined calls to C functions (saved in the state) crash the session if (and only if) the foreign call was called in an earlier session before the state was saved. I can supply an example if necessary.
After investigating, it is actually malloc that is failing in the calls. Surprisingly, the very first malloc in the session finds an existing address. As freeList is emptied by PolyML.onEntry presumably freeList is being restored by loadState. Does that sound like an issue? I would expect that the freeList state is untouched by loadState.
I think you're right. It looks as though freeList is an ordinary ref. It should be a special ref that isn't set by loading the state. These are used in the basis library particular for IO streams. I've just pushed that change to a new branch - No-overwrite-test. Could you check if that fixes the problem?
David
David,
On 19/01/2016 19:14, David Matthews wrote:
Phil,
On 19/01/2016 18:38, Phil Clayton wrote:
After loading an existing state in a fresh session, I find that previously defined calls to C functions (saved in the state) crash the session if (and only if) the foreign call was called in an earlier session before the state was saved. I can supply an example if necessary.
After investigating, it is actually malloc that is failing in the calls. Surprisingly, the very first malloc in the session finds an existing address. As freeList is emptied by PolyML.onEntry presumably freeList is being restored by loadState. Does that sound like an issue? I would expect that the freeList state is untouched by loadState.
I think you're right. It looks as though freeList is an ordinary ref. It should be a special ref that isn't set by loading the state. These are used in the basis library particular for IO streams. I've just pushed that change to a new branch - No-overwrite-test. Could you check if that fixes the problem?
Thanks for the quick patch - that fixes it. Also, I modified my version with diagnostic messages and now see the expected messages from malloc.
Phil
On 19/01/2016 19:48, Phil Clayton wrote:
Thanks for the quick patch - that fixes it. Also, I modified my version with diagnostic messages and now see the expected messages from malloc.
Thanks for testing it. Now merged into master.
David
-
David.Matthews＠prolingua.co.uk -
phil.clayton＠lineone.net