Can we have a bit more information regarding this error:
SU_ERROR_SERIALIZATION if the serialization operation itself fails
It happens in SUModelSaveToFileWithVersion() when trying to create a very large SketchUp file. I’m not sure of the exact size it would be, but probably in the realm of several GBs. Is there a file size limit the SDK can produce?
I bothered Thomas about this last year in a tracking issue …
I suggest you add any other methods where this “serialization” is mentioned.
I suspect it just mean whilst writing to the file’s DOM tree.
One possibility: I see this when I attempt to write a model file that is already open in SketchUp.
In this case, the file doesn’t exist yet.
SU_ERROR_SERIALIZATION is returned if:
false. there is no further details given back to the API)
Are you able to provide a simple repro? I can then run it through the debugger and see where it fails.
No, we’re able to reproduce it only with a single large FBX model loaded in Transmutr
If I provide a Transmutr license and the model, can you run the debugger?
I can try.
Does the C API contain debug symbols?
Afraid we cannot distribute that - would expose too much of our internals.
Ok, so I guess the debugger won’t tell you much…
If you still want to try, I believe you have a Transmutr license. PM me if you can’t find it.
The model is here: Cant get a sketchup file generated from this model - Bug reports - Lindalë forums
Does it help if I give you a version of Transmutr with our own debug symbols?
Oh I just realized, you can swap DLLs?
In Transmutr, SketchUpAPI.dll is located in:
C:\Program Files\Transmutr\resources\app.asar.unpacked\_webpack if installed “per-machine”C:\Users\thomthom\AppData\Local\Programs\Transmutr\resources\app.asar.unpacked\_webpack if installed “per-user”Let me know if you need anything else.
One more thing.
We use Electron, so the easiest is to attach the debugger once Transmutr is already launched. Electron uses multiple processes, so you might need to try a few of them. Usually, the first process in the debugger selection window is the one, but that’s not true 100% of the time.
@tt_su Where you able to take a look at this?
Looking now.
How long does the export usually take before it crashes? (Been running for a while now. Transmutr’s memory usage is up at ~8GB)
…and it just completed without crashing.
I loaded the FBX from that other thread and exported as SKP without adjusting anything.
Transmutr doesn’t crash, but SUModelSaveToFileWithVersion() returns SU_ERROR_SERIALIZATION
We handle the error to avoid a crash, but no .skp file is being generated. That’s what I was asking: can you check why we get SU_ERROR_SERIALIZATION in this case?
Thanks for looking into this!
It’s failing to copy the temp file to the target location for some reason.
I see the temp skp* file being written to C:\Users\tthomas2\AppData\Local\Temp - but post-write checks for the file before copying fails.
When I tried to copy the temp file to my desktop and append .skp to it SketchUp appear to crash. So I’m not sure yet what is causing all this. The file is ~2.5 GB - I’m not sure if the filesize itself is causing problems with some of the system file functions we are calling…
Hm… The written file is 2 565 944 356 bytes… And before copying the temp file we use _wstat which according to MS docs says supports only 32bit file lengths: _stat, _stat32, _stat64, _stati64, _stat32i64, _stat64i32, _wstat, _wstat32, _wstat64, _wstati64, _wstat32i64, _wstat64i32 | Microsoft Learn
I’ll to more tests tomorrow, but I suspect this is the culprit. (I tried to load the temp file again, and this time it worked.)
If this is the case, then I think the only workaround you can use right now is to check the temp directory for a skp* (skp2 or skp3 etc.) is try to manually move it after a failed serialization. It’s a bit fragile and relies on implementation details, so mileage might vary. At least you can instruct your users to try to manually recover the file.
