Crash Scenario (duk_dup_top and embedding JSON object data within itself) - Solved about duktape HOT 4 CLOSED

It's not actually a crash but an uncaught error which causes a fatal error and an abort():

*** FATAL ERROR: uncaught: 'cyclic input'

If you wrap the test in a duk_safe_call() you'll get an ordinary error out of it.

The reason that JSON encode/decode helps is because you'll be creating a new object so it removes the cyclic result. To illustrate, before the JSON encode/decode the structure will look like this:

{ x: 'x' }  ->  { x: 'x', savecopy: [x] }
   ^                                 |
   `---------------------------------'

which contains a cycle and will serialize to an infinite JSON output.

After the JSON encode/decode it will look like this:

{ x: 'x' }  ->  { x: 'x', savecopy: [x] }
                                     |
                                     `----> { x: 'x' }

which is cycle free.

The issue here is that duk_push_context_dump() doesn't deal with cyclic structures at present. Ideally it would replace the cycle with a placeholder or such.

from duktape.

Many thanks for the very clear explanation, it does make sense to me.

I am trying to get the info copied into 'savecopy' - so I guess the function I am looking for is duk_copy_top() - i.e. I definitely don't want the infinitely linked scenario as you have described in your post, as I want to be able to change the first value of 'x' but not the nested value.

Is there a more elegant way to achieve what I am looking for than duk_dup_top(), duk_json_encode(), duk_json_decode()?

Again, thanks!

Steve

from duktape.

In general making a deep copy of an arbitrary object is non-trivial for several reasons (loops or shared objects in a DAG arrangement, native properties like file handles, etc), and different use cases may require slightly different approaches. There's currently no direct API to do that, so you'd have to implement a deep copy yourself in some way.

The closest you can probably get now, out of the box, is duk_cbor_encode() + duk_cbor_decode(). This is faster than a JSON encode/decode round trip, and supports more data types than JSON serialization which might matter in some cases.

If the input is always an object decoded from JSON, this way of cloning should be equivalent to JSON cloning, but just a bit faster.

Finally, if the input is always a JSON string, you could also just decode it twice to get two independent copies of the same logical object which saves the JSON encode operation in the cloning process.

Hope this helps :)

from duktape.

Many thanks for your clear and comprehensive responses.
S.

from duktape.