... | @@ -795,6 +795,10 @@ func (r *RestAPI) DeleteSession(ctx context.Context, params users.DeleteSessionP |
... | @@ -795,6 +795,10 @@ func (r *RestAPI) DeleteSession(ctx context.Context, params users.DeleteSessionP |
|
* In Kea, loading a hook library of a different version can cause a memory corruption which can lead to the termination of the core server. The more functions you call from the hook library, the greater the chance of the corruption to happen. While this is more acceptable in a process like Kea which can be restarted with a fallback configuration, you probably want Stork processes to be more resilient to this type of situations so that an error message survives to the GUI. The version check helps in preventing a crash. However, the version check itself involves Open()-ing the library and calling a function per this design. Since the version is known to return a string (or two per the design, I can't figure out why) this could be reduced to a simple variable which can be Lookup()-ed, which is arguably more safe, and also consistent with the core representation of a version which is also a simple string. I would advise testing and observing how the go plugin modules behaves in this case. Checking the version before calling Load() helps as well. Kea issue 2428 documents how you can get a reliable segfault by loading another version's hook library. It seems it is caused by dlclose() so the lack of it here may also help and may have been by design. (Andrei)
|
|
* In Kea, loading a hook library of a different version can cause a memory corruption which can lead to the termination of the core server. The more functions you call from the hook library, the greater the chance of the corruption to happen. While this is more acceptable in a process like Kea which can be restarted with a fallback configuration, you probably want Stork processes to be more resilient to this type of situations so that an error message survives to the GUI. The version check helps in preventing a crash. However, the version check itself involves Open()-ing the library and calling a function per this design. Since the version is known to return a string (or two per the design, I can't figure out why) this could be reduced to a simple variable which can be Lookup()-ed, which is arguably more safe, and also consistent with the core representation of a version which is also a simple string. I would advise testing and observing how the go plugin modules behaves in this case. Checking the version before calling Load() helps as well. Kea issue 2428 documents how you can get a reliable segfault by loading another version's hook library. It seems it is caused by dlclose() so the lack of it here may also help and may have been by design. (Andrei)
|