fungos/cr

help needed

questor opened this issue · 5 comments

questor commented

Hi,
live reloading isn't working for me on linux, here the facts I've debugged so far:

  • your repository with the imgui-sample reloading in linux works!
  • my project on windows reloading works
  • my project on linux 64bit does NOT work!

So the issue is clearly from my project setup, your sample is working. I've tried to debug this and found out:

  • library is copied successfully
  • new library is loaded (lsof -p shows the new library and debug logs also indicate that the new so is loaded). Old library is marked as "DEL"
  • I've checked md5 sums of the files and for the reloaded library and they're different (original vs runtime-modified library)
  • my project works, but code-changes done are compiled (shared library size changes, md5sum changes), are loaded (checked via lsof) but still old code is executed

any ideas how to find out what is going on and why it doesn't work? I'm not sure if I can trust qtcreator-debugger when I step through the source code, but on assembly level it looks like the old function (old debugging info also might happen). Or any sanity-checks I can do?

fungos commented

Hard to tell, I'll give some shots:

  1. This maybe an issue caused by a problem managing the data sections (.bss or .state). You will need to debug what is happening with your project during the cr_plugin_load_internal (try to put a breakpoint on the returns returning false). I believe it should be failing here but it may very well be another thing.

Also, you can check what changes in your .so after a recompilation by checking its sections (readelf or objdump), this may give some extra information (mostly if offset/address changes).

  1. You say logs tell the library was loaded, so what exactly does not work on your project? Do you see the new .so renamed being used in lsof? (If you lib is foo.so, the loaded object will be like foo0.so, foo1.so, foo2.so, ...). So if you say it works on windows but not on linux, maybe the project output path/name may be the issue.

  2. If you're able to debug and think the old library is loaded, can you validate within GDB the loaded shared objects to make sure the latest version is loaded (info sharedlibrary) ? Also, are you sure a rollback didn't happened trying to load the most recent version of the .so?

questor commented

ufff..... found the issue. your advices did help in the end, I've checked even down to the assembly that the libraries had changed code and that the libraries were reloaded, but the "info sharedlibrary" gave me the hint that I loaded the library in a proper way, but the build system I'm using had a reference to the library as well with the result that I had the original shared library loaded IN ADDITION to the shared libraries loaded by your implementation. and it seems that the reference placed by the linker has a higher priority than the loaded one.

many thanks for the help!!

  • 👍1
fungos commented

Glad to hear you found it.

Is there anything that we should put in the readme about this situation? I mean, if it is something that someone else may find in the future?

  • 👍1
questor commented

I also thought about that, the only thing comes in my mind is to write a sentence to NOT link to the dynamically loaded shared library via the build system. the other things like "info sharedlibrary" and "lsof -p " might be useful in a "deepdive debug info" section, but most people should not need that.

  • 👍1
fungos commented

I think it is valid. I'll write something in the FAQ section, thank you for reporting this!

  • 👍1