I would like to know how to do a catch in a cmod. I happen to use f_string_to_utf8 now and it throws on non unicode chars, so I have to free some mem.
arne
ONERROR handle; SET_ONERROR (handle, my_free_function, my_mem); /* do stuff which may throw */ UNSET_ONERROR (handle);
If you want my_free_function to be called even if nothing was thrown, use CALL_AND_UNSET_ONERROR instead.
ONERROR handle; SET_ONERROR (handle, my_free_function, my_mem); /* do stuff which may throw */ UNSET_ONERROR (handle);
If you want my_free_function to be called even if nothing was thrown, use CALL_AND_UNSET_ONERROR instead.
That's probably the proper solution in this case, but it's not quite a catch...
JMP_BUF ctx;
if (SETJMP(ctx)) { /* Something was thrown. */ } else { /* Some code that might throw. */ } UNSETJMP(ctx);
I think I will use the first one then. Are there any potential problems.. except for some code using longjmp() directly?
On Sat, 23 Aug 2008, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
ONERROR handle; SET_ONERROR (handle, my_free_function, my_mem); /* do stuff which may throw */ UNSET_ONERROR (handle);
If you want my_free_function to be called even if nothing was thrown, use CALL_AND_UNSET_ONERROR instead.
That's probably the proper solution in this case, but it's not quite a catch...
JMP_BUF ctx;
if (SETJMP(ctx)) { /* Something was thrown. */ } else { /* Some code that might throw. */ } UNSETJMP(ctx);
This looks like it would be quite reasonable to always do this right after I alloc something. I actually found a memory leak in my JSON2 code when testing on pike 7.7 because string_to_utf8 potentially throws now (I think that was not there in pike 7.6). I have the feeling that there are more leaks of this types out there, especially because throwing behaviour may/did change.
When having a quick look I found that in Math.transforms in rIFFT() there are several Pike_error() calls after malloc. I guess that that part of Math is not really used much, especially because librfftw does not seem to be compatible anymore (may be wrong here).
I can write a patch later... there are also some typos I found some time ago when reading the docs.
arne
On Sat, 23 Aug 2008, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
ONERROR handle; SET_ONERROR (handle, my_free_function, my_mem); /* do stuff which may throw */ UNSET_ONERROR (handle);
If you want my_free_function to be called even if nothing was thrown, use CALL_AND_UNSET_ONERROR instead.
The easiest way is to allocate things to objects, and clear up things when the objects get garbaged, and not keep pointers to temporary data on the C stack. Then you don't really have to catch anything (unless you want to). :)
Hm, i see. So in case of Math.transforms its not actually a leak. I wasnt looking close enough.
Not sure if I want to use something similar in my situation. Parsing json does not really require any state unless you want to do the parsing in smaller chunks.
On Sat, 23 Aug 2008, Mirar @ Pike developers forum wrote:
The easiest way is to allocate things to objects, and clear up things when the objects get garbaged, and not keep pointers to temporary data on the C stack. Then you don't really have to catch anything (unless you want to). :)
/.../ I actually found a memory leak in my JSON2 code when testing on pike 7.7 because string_to_utf8 potentially throws now (I think that was not there in pike 7.6). /.../
It could throw earlier too, just not quite so often since it didn't check for strict utf8 compliance.
In general, one must always assume that any pike callable function might throw (they do argument checks, if nothing else). For lower level functions it's a mix; if unsure, one should either check it out in the source or assume they might throw too.
If we get around cleaning up the C-level interface, we should clearly mark if a function might throw or not. I'd actually like that it'd be coded into the name with a "t_" prefix or something.
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum