search

fungos / cr

cr.h: A Simple C Hot Reload Header-only Library
https://fungos.github.io/cr-simple-c-hot-reload/
MIT License
1.56k stars 104 forks source link

[Linux] Crash on reload #5

Closed rokups closed 6 years ago

rokups commented 6 years ago

Hello! I am experimenting with your library and i bumped into odd issue. Basically i have my libAwesomeGame.so which exports cr_main and does the proper thing. Library is loaded and executed fine. However if i trigger reload by say doing touch libAwesomeGame.so i get crash at this line. Both p->data[sec][0].data and p->data[sec][0].size are null. Any idea why that could be happening?

Figured you might find game library useful so here it is: libAwesomeGame.tar.gz

fungos commented 6 years ago

You can try this update? Otherwise, I couldn't get your lib to work, so you may want to do some logging/printf on cr_elf_section_save. Another thing, you may try to change the state saving mode by defining your CR_HOST as CR_DISABLE or CR_SAFEST just to be sure everything else is working correctly with Urhol3D.

rokups commented 6 years ago

Hey thank you for quick fix, that did the trick! And it works with default behaviour now (defining CR_HOST to empty value).

Since there is no other place to ask please allow me to voice few (offtopic to this bug) questions regarding cr :) I do know that scope of safe changes is limited, however i am still trying to gauge that scope. I know that changing data structures is unsafe, but i suspect that code changes are unsafe as well. Say i modify some code in a method, add a good chunk of logic. It has a potential to shift addresses of methods that come after. So if any of these methods are virtual then objects created by reloadable module would no longer contain valid entries in virtual method table, right? I consulted with someone else and they said the only sensible approach is to serialize state on unload and unserialize state on load. Is that really the case and no workarounds available?

fungos commented 6 years ago

Unfortunately that is the case. With cr.h you can manually manage this when receiving CR_UNLOAD. But C++ is a complex beast and a lot can go wrong anyway. If you do really want automatic and safe C++ support, you're better of with the excellent RCCPP. It is a bit more complex than cr.h, but it does complex things due C++ being complex. :)

rokups commented 6 years ago

I am experimenting with using cr.h for injecting user components to 3d scene editor. At least for this usecase serializing/deserializing things looks acceptable to me. Since you know a great deal on this topic could you please elaborate on what exactly RCCPP does what cr.h does not? Knowing details will help me to avoid shooting myself in the foot eventually ;)

Edit: actually i think i found all the answers: http://www.gameaipro.com/GameAIPro/GameAIPro_Chapter15_Runtime_Compiled_C++_for_Rapid_AI_Development.pdf Thanks again :)

fungos commented 6 years ago

Yup, all the answers are there! You can see really well how rccpp and cr differs there as cr is a really simple and dumb solution but good enough to get the basics of hot-reloading working.