[jira] [Created] (CELIX-229) Make APR optional
Alexander Broekhuis created CELIX-229: - Summary: Make APR optional Key: CELIX-229 URL: https://issues.apache.org/jira/browse/CELIX-229 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis Even though APR is still not yet completely removed from all different subproject, it is save enough to make APR optional. To do this the following is needed: * Add a build option to enable/disable APR * Create a header file with define for APR usage in the source (when APR is used, the framework has to provide it to the bundles) * Add dependency to subprojects needing APR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-90) add additional build options for RSA components
[ https://issues.apache.org/jira/browse/CELIX-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14325801#comment-14325801 ] Alexander Broekhuis commented on CELIX-90: -- I've added some additional build options to the build. Can you please check if this makes sense? add additional build options for RSA components --- Key: CELIX-90 URL: https://issues.apache.org/jira/browse/CELIX-90 Project: Celix Issue Type: Improvement Affects Versions: 0.0.1-incubating Reporter: Bjoern Petri Attachments: rsaCmakeBuildOptions.patch As discussed with Alexander, I created a patch which allows to enable the Remote Service Admin Bundles in general as well as the single RSA components. This allows me to build the Remote Services Admin without having e.g. a bonjour dependency. For now I stumble over the problem that I can enable the deployment of the calculator example including the discovery_bonjour component but disable the build of the discovery_bonjour component itself. Although the dependency to the discovery_slp is added in the deployment configuration it cannot be enabled (and therefore integrated) anymore as the deployment takes place in the very last step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-215) curl_global_init() not called directly
[ https://issues.apache.org/jira/browse/CELIX-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-215. --- Resolution: Fixed Fix Version/s: next curl_global_init() not called directly -- Key: CELIX-215 URL: https://issues.apache.org/jira/browse/CELIX-215 Project: Celix Issue Type: Bug Reporter: Daniel Parker Assignee: Alexander Broekhuis Priority: Minor Fix For: next curl_global_init() is called by curl_easy_init() if it has not been called already (so the system works as-is), but according to the documentation, curl_global_init() is not thread-safe, so it really ought to be called in launcher.c::main() before it starts spawning threads. Also, curl_global_cleanup() needs to be called after we're done with curl. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-219) Memory Leaks
[ https://issues.apache.org/jira/browse/CELIX-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315789#comment-14315789 ] Alexander Broekhuis commented on CELIX-219: --- Thanks for those reports, I'll go through time file by file, starting with the framework; logger: no specific remarks, needs to be fixed installedBundleMap: The key is already free'd, the values should not be free'd as those need to be removed from the map during shutdown of the framework. See the uninstall for more details. mutexes/conditions: needs to be fixed loadLibrary: needs to be fixed uninstall: This one is a bit more tricky, though probably not even that hard to fix. The issue is that during shutdown, active bundles should not be marked as uninstalled, this of course does not mean that it's resources should not be cleaned. So I'm going to look at the shutdown thread, and see if I can add something there. Probably have to add a flag to the uninstall function so that it does not record the state (similar to what stop already does). Memory Leaks Key: CELIX-219 URL: https://issues.apache.org/jira/browse/CELIX-219 Project: Celix Issue Type: Bug Reporter: Daniel Parker Priority: Minor framework.c: framework_create() allocates memory for logger, but framework_destroy does not free() it. framework_destroy() when destroying framework-installedBundleMap should set the second argument to true in order to free the memory allocated for the keys. framework_destroy() should destroy the mutexes/conditions created by framework_create(). framework_loadLibrary() should clear the entire libraryPath string before using it. fw_uninstallBundle() should only call fw_stopBundle() if the bundle is in the OSGI_FRAMEWORK_BUNDLE_ACTIVE state. The proxy/endpoint bundles get uninstalled correctly, but the normal bundles do not get uninstalled. This might be resolved by letting framework_shutdown() call fw_uninstallBundle() for every bundle (except for the system framework bundle) in the installedBundleMap after it's done stopping all of the bundles. Alternately, the bundles could be uninstalled in framework_destroy(), but fw_uninstallBundle() (and bundle_uninstall() ) wouldn't work at this point because the dispatcherThread would already have been canceled. bundle.c: The function bundle_addModule() does not have a corresponding bundle_removeModule(). This is because modules are added one at a time but removed all at once. However, the code which remove the modules in bundle_destroy() needs to call resolver_removeModule() in order for this to work properly. The function bundle_isUsed() looks incorrect/incomplete in how it uses module_getDependents(). However, the function isn't actually used so it's probably easier to just remove it than to try to fix it. bundle_closeModules() looks like it should be calling module_destroy() rather than module_setWires(). And it looks like it should call arrayList_clear(bundle-modules) when it's done. resolver.c: m_modules is created but never destroyed. Perhaps it could be destroyed whenever it's empty? m_unresolvedServices/m_resolvedServices are never destroyed and none of the elements added to them are ever destroyed either. Perhaps each element should be destroyed if they become empty and m_unresolvedServices/m_resolvedServices should be destroyed once it contains no elements? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CELIX-219) Memory Leaks
[ https://issues.apache.org/jira/browse/CELIX-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315789#comment-14315789 ] Alexander Broekhuis edited comment on CELIX-219 at 2/11/15 8:39 AM: Thanks for those reports, I'll go through them file by file, starting with the framework; logger: no specific remarks, needs to be fixed installedBundleMap: The key is already free'd, the values should not be free'd as those need to be removed from the map during shutdown of the framework. See the uninstall for more details. mutexes/conditions: needs to be fixed loadLibrary: needs to be fixed uninstall: This one is a bit more tricky, though probably not even that hard to fix. The issue is that during shutdown, active bundles should not be marked as uninstalled, this of course does not mean that it's resources should not be cleaned. So I'm going to look at the shutdown thread, and see if I can add something there. Probably have to add a flag to the uninstall function so that it does not record the state (similar to what stop already does). was (Author: abroekhuis): Thanks for those reports, I'll go through time file by file, starting with the framework; logger: no specific remarks, needs to be fixed installedBundleMap: The key is already free'd, the values should not be free'd as those need to be removed from the map during shutdown of the framework. See the uninstall for more details. mutexes/conditions: needs to be fixed loadLibrary: needs to be fixed uninstall: This one is a bit more tricky, though probably not even that hard to fix. The issue is that during shutdown, active bundles should not be marked as uninstalled, this of course does not mean that it's resources should not be cleaned. So I'm going to look at the shutdown thread, and see if I can add something there. Probably have to add a flag to the uninstall function so that it does not record the state (similar to what stop already does). Memory Leaks Key: CELIX-219 URL: https://issues.apache.org/jira/browse/CELIX-219 Project: Celix Issue Type: Bug Reporter: Daniel Parker Priority: Minor framework.c: framework_create() allocates memory for logger, but framework_destroy does not free() it. framework_destroy() when destroying framework-installedBundleMap should set the second argument to true in order to free the memory allocated for the keys. framework_destroy() should destroy the mutexes/conditions created by framework_create(). framework_loadLibrary() should clear the entire libraryPath string before using it. fw_uninstallBundle() should only call fw_stopBundle() if the bundle is in the OSGI_FRAMEWORK_BUNDLE_ACTIVE state. The proxy/endpoint bundles get uninstalled correctly, but the normal bundles do not get uninstalled. This might be resolved by letting framework_shutdown() call fw_uninstallBundle() for every bundle (except for the system framework bundle) in the installedBundleMap after it's done stopping all of the bundles. Alternately, the bundles could be uninstalled in framework_destroy(), but fw_uninstallBundle() (and bundle_uninstall() ) wouldn't work at this point because the dispatcherThread would already have been canceled. bundle.c: The function bundle_addModule() does not have a corresponding bundle_removeModule(). This is because modules are added one at a time but removed all at once. However, the code which remove the modules in bundle_destroy() needs to call resolver_removeModule() in order for this to work properly. The function bundle_isUsed() looks incorrect/incomplete in how it uses module_getDependents(). However, the function isn't actually used so it's probably easier to just remove it than to try to fix it. bundle_closeModules() looks like it should be calling module_destroy() rather than module_setWires(). And it looks like it should call arrayList_clear(bundle-modules) when it's done. resolver.c: m_modules is created but never destroyed. Perhaps it could be destroyed whenever it's empty? m_unresolvedServices/m_resolvedServices are never destroyed and none of the elements added to them are ever destroyed either. Perhaps each element should be destroyed if they become empty and m_unresolvedServices/m_resolvedServices should be destroyed once it contains no elements? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CELIX-220) Rewrite resolver to be a ADT
Alexander Broekhuis created CELIX-220: - Summary: Rewrite resolver to be a ADT Key: CELIX-220 URL: https://issues.apache.org/jira/browse/CELIX-220 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis Currently the resolver is not an ADT, and it uses several global variables. This makes it difficult to know when the resolver can be completely destroyed, resulting in possible memory leaks. While those leaks can be fixed, I think it makes more sense to rewrite/refactor to code to an actual ADT. This also fits better wrt the rest of the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-219) Memory Leaks
[ https://issues.apache.org/jira/browse/CELIX-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316206#comment-14316206 ] Alexander Broekhuis commented on CELIX-219: --- I've been working on those issues, to summarize: Framework: - Fixed several small issues (see commits related to this issue). - Updated framework destroy to close bundles and libraries. This results in the removal of the modules in the resolver. This change also takes care of emptying the installedBundleMap, so in the destroy the keys/values can be left untouched. Resolver: - With the call to bundle_close, modules are now removed. If the module list is empty, the lists are destroyed/NULLed. Also updated the bundle to not add a module multiple times, which would have prevented the list from even being empty. - I can't detect any other leaks using Valgrind, but the Resolver is currently not an ADT and very verbose to read/understand, so I've create an issue for refactoring/rewriting it. Bundle: - bundle_closeModules is called by bundle_close. This call takes care of removing the modules from the resolver. Previously bundle_close was never called, as mentioned I've added this to framework. - I've removed isUsed, if it is needed later on we can always resurrect it from SVN. - bundle_closeModules closes the modules, it does not destroy them. That is done in bundle_destroy, where the list is also destroyed. Are you seeing any problems with this currently? Not sure if I now missed something, if there are still some leaks, feel free to comment to this issue (or open a new one). Memory Leaks Key: CELIX-219 URL: https://issues.apache.org/jira/browse/CELIX-219 Project: Celix Issue Type: Bug Reporter: Daniel Parker Priority: Minor framework.c: framework_create() allocates memory for logger, but framework_destroy does not free() it. framework_destroy() when destroying framework-installedBundleMap should set the second argument to true in order to free the memory allocated for the keys. framework_destroy() should destroy the mutexes/conditions created by framework_create(). framework_loadLibrary() should clear the entire libraryPath string before using it. fw_uninstallBundle() should only call fw_stopBundle() if the bundle is in the OSGI_FRAMEWORK_BUNDLE_ACTIVE state. The proxy/endpoint bundles get uninstalled correctly, but the normal bundles do not get uninstalled. This might be resolved by letting framework_shutdown() call fw_uninstallBundle() for every bundle (except for the system framework bundle) in the installedBundleMap after it's done stopping all of the bundles. Alternately, the bundles could be uninstalled in framework_destroy(), but fw_uninstallBundle() (and bundle_uninstall() ) wouldn't work at this point because the dispatcherThread would already have been canceled. bundle.c: The function bundle_addModule() does not have a corresponding bundle_removeModule(). This is because modules are added one at a time but removed all at once. However, the code which remove the modules in bundle_destroy() needs to call resolver_removeModule() in order for this to work properly. The function bundle_isUsed() looks incorrect/incomplete in how it uses module_getDependents(). However, the function isn't actually used so it's probably easier to just remove it than to try to fix it. bundle_closeModules() looks like it should be calling module_destroy() rather than module_setWires(). And it looks like it should call arrayList_clear(bundle-modules) when it's done. resolver.c: m_modules is created but never destroyed. Perhaps it could be destroyed whenever it's empty? m_unresolvedServices/m_resolvedServices are never destroyed and none of the elements added to them are ever destroyed either. Perhaps each element should be destroyed if they become empty and m_unresolvedServices/m_resolvedServices should be destroyed once it contains no elements? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-215) curl_global_init() not called directly
[ https://issues.apache.org/jira/browse/CELIX-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14309677#comment-14309677 ] Alexander Broekhuis commented on CELIX-215: --- Looking at the API of curl, I see how it is intended to use. But looking at the principle idea of Celix (or OSGi in general) I do not see how to fit the current usage of Curl in Celix. To clarify, following the spec bundles are loaded unordered, while there currently is a side effect of the launcher, this is not something we can rely on. Also, any bundle can use Curl, as such the start/stop point of Curl is not known. One possible (partial) solution would be to create a separate Curl bundle that takes care of the global_init and global_destroy calls. Any bundle wanting to use Curl would depend on this bundle. So in turn curl_easy_init is only used when the Curl bundle is started. This, however, does not satisfy the Curl requirement that no threads must be started before calling global_init, because any other bundle not using Curl can already be started and have started threads as well. I'll think about this a bit more. Any ideas are welcome as well! curl_global_init() not called directly -- Key: CELIX-215 URL: https://issues.apache.org/jira/browse/CELIX-215 Project: Celix Issue Type: Bug Reporter: Daniel Parker Priority: Minor curl_global_init() is called by curl_easy_init() if it has not been called already (so the system works as-is), but according to the documentation, curl_global_init() is not thread-safe, so it really ought to be called in launcher.c::main() before it starts spawning threads. Also, curl_global_cleanup() needs to be called after we're done with curl. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CELIX-214) Unsafe strtok() usage
[ https://issues.apache.org/jira/browse/CELIX-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis closed CELIX-214. - Resolution: Duplicate Closed, since CELIX-216 will solve this one. Unsafe strtok() usage - Key: CELIX-214 URL: https://issues.apache.org/jira/browse/CELIX-214 Project: Celix Issue Type: Bug Reporter: Daniel Parker start_command.c::startCommand_execute() cannot use strtok() safely because strtok() is used by some of the functions that end up being invoked by it on down the line. Valgrind stack trace of the error: ==28542==by 0x1F0EDD53: endpointDiscoveryPoller_create (endpoint_discovery_poller.c:99) ==28542==by 0x1F0EBF4B: discovery_start (discovery_impl.c:81) ==28542==by 0x1F0EC2D3: bundleActivator_start (discovery_activator.c:141) ==28542==by 0x4857A5B: fw_startBundle (framework.c:700) ==28542==by 0x484E783: bundle_startWithOptions (bundle.c:311) ==28542==by 0x56FD45F: startCommand_execute (start_command.c:67) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CELIX-216) Replace strtok with strtok_r
Alexander Broekhuis created CELIX-216: - Summary: Replace strtok with strtok_r Key: CELIX-216 URL: https://issues.apache.org/jira/browse/CELIX-216 Project: Celix Issue Type: Improvement Reporter: Alexander Broekhuis Currently strtok is used in several places. While on a first inspection this is ok in most places, there are several side-effects when a function using strtok is called inside a strtok invocation as well. This is not obvious at first sight, so using strtok is risky at best. To prevent this strtok should be replaced with strtok_r, which provides an API in which a pointer can be used to keep track of the strtok invocation. strtok is used in: * launcher.c:123 main * discovery -- endpoint_discovery_poller.c:93 endpointDiscoveryPoller_create * remote_service_admin_http -- remote_service_admin_impl.c:394 remoteServiceAdmin_exportService -- remote_service_admin_impl.c:400 remoteServiceAdmin_exportService -- remote_service_admin_impl.c:402 remoteServiceAdmin_exportService * remote_service_admin_shm -- remote_service_admin_impl.c:487 remoteServiceAdmin_exportService -- remote_service_admin_impl.c:493 remoteServiceAdmin_exportService -- remote_service_admin_impl.c:495 remoteServiceAdmin_exportService * shell -- help_command.c:65 helpCommand_execute -- install_command.c:61 installCommand_execute -- ps_command.c:67 psCommand_execute -- start_command.c:55 startCommand_execute -- stop_command.c:56 stopCommand_execute -- uninstall_command.c:57 uninstallCommand_execute -- update_command.c:63 updateCommand_execute -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CELIX-210) Remove old Dependency Manager
Alexander Broekhuis created CELIX-210: - Summary: Remove old Dependency Manager Key: CELIX-210 URL: https://issues.apache.org/jira/browse/CELIX-210 Project: Celix Issue Type: Task Components: Dependency Manager Reporter: Alexander Broekhuis With the new DM implementation, the old one can be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CELIX-208) Remove APR from examples
Alexander Broekhuis created CELIX-208: - Summary: Remove APR from examples Key: CELIX-208 URL: https://issues.apache.org/jira/browse/CELIX-208 Project: Celix Issue Type: Task Components: Examples Reporter: Alexander Broekhuis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CELIX-209) Remove APR from Remote Services
Alexander Broekhuis created CELIX-209: - Summary: Remove APR from Remote Services Key: CELIX-209 URL: https://issues.apache.org/jira/browse/CELIX-209 Project: Celix Issue Type: Task Components: Remote Service Admin Reporter: Alexander Broekhuis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-204) endpoints do not remain registered after the Remote Discovery (Configured) bundle restarts
[ https://issues.apache.org/jira/browse/CELIX-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-204. --- Resolution: Fixed Fix Version/s: next-incubating Pushed a fix for this, please check it out and if it is ok, close this issue. Thanks for reporting! endpoints do not remain registered after the Remote Discovery (Configured) bundle restarts -- Key: CELIX-204 URL: https://issues.apache.org/jira/browse/CELIX-204 Project: Celix Issue Type: Bug Components: Remote Service Admin Environment: REV 1652984 Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating If you restart the apache_celix_rsa_discovery_configured bundle, it will no longer show the endpoints that had been registered. Note: if you re-register the endpoints, then they will show up again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CELIX-204) endpoints do not remain registered after the Remote Discovery (Configured) bundle restarts
[ https://issues.apache.org/jira/browse/CELIX-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis reassigned CELIX-204: - Assignee: Alexander Broekhuis endpoints do not remain registered after the Remote Discovery (Configured) bundle restarts -- Key: CELIX-204 URL: https://issues.apache.org/jira/browse/CELIX-204 Project: Celix Issue Type: Bug Components: Remote Service Admin Environment: REV 1652984 Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating If you restart the apache_celix_rsa_discovery_configured bundle, it will no longer show the endpoints that had been registered. Note: if you re-register the endpoints, then they will show up again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-205) RSA Discovery (Configured) bundle gets stuck
[ https://issues.apache.org/jira/browse/CELIX-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14293048#comment-14293048 ] Alexander Broekhuis commented on CELIX-205: --- Looking at this issue, I couldn't find any obvious cause at the moment. But there are several solutions that can be tried: 1) I've updated the civetweb source to the latest version, that seems to help 2) The discovery poller thread uses libcurl, libcurl is known to have problems with multiple threads and DNS request. They provide a threaded solution which needs to be enabled specifically. Basically when a DNS request fails, an alarm is sent, but without threading support this might be to the incorrect thread. (see http://curl.haxx.se/libcurl/c/CURLOPT_NOSIGNAL.html and http://daniel.haxx.se/blog/2011/04/25/libcurls-name-resolving) At this point I suspect that a combination of those 2 items are the problem. Could you try with the current Trunk and make sure libcurl supports threading for the DNS lookup? RSA Discovery (Configured) bundle gets stuck Key: CELIX-205 URL: https://issues.apache.org/jira/browse/CELIX-205 Project: Celix Issue Type: Bug Components: Remote Service Admin Environment: REV 1652984 Reporter: Daniel Parker Assignee: Alexander Broekhuis Priority: Blocker Under certain situations, the apache_celix_rsa_discovery_configured bundle will get stuck somehow and attempts to connect to it to get the list of registered endpoints will time out. When this happens, the bundle cannot be stopped from the shell (and the apache_celix_rs_topology_manager and apache_celix_remote_service_admin_http bundles have similar problems) This is difficult to reproduce. Sometimes the bundle runs fine for a short time after the program is started and then it breaks (perhaps after endpoints or proxies are accessed). Other times the bundle works fine and doesn't get stuck at all. The issue will only happen if there is actually a remote that is being connected to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CELIX-205) RSA Discovery (Configured) bundle gets stuck
[ https://issues.apache.org/jira/browse/CELIX-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis reassigned CELIX-205: - Assignee: Alexander Broekhuis RSA Discovery (Configured) bundle gets stuck Key: CELIX-205 URL: https://issues.apache.org/jira/browse/CELIX-205 Project: Celix Issue Type: Bug Components: Remote Service Admin Environment: REV 1652984 Reporter: Daniel Parker Assignee: Alexander Broekhuis Priority: Blocker Under certain situations, the apache_celix_rsa_discovery_configured bundle will get stuck somehow and attempts to connect to it to get the list of registered endpoints will time out. When this happens, the bundle cannot be stopped from the shell (and the apache_celix_rs_topology_manager and apache_celix_remote_service_admin_http bundles have similar problems) This is difficult to reproduce. Sometimes the bundle runs fine for a short time after the program is started and then it breaks (perhaps after endpoints or proxies are accessed). Other times the bundle works fine and doesn't get stuck at all. The issue will only happen if there is actually a remote that is being connected to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-189) LogService segfaults when log message pointer is overwritten
[ https://issues.apache.org/jira/browse/CELIX-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-189. --- Resolution: Fixed Fixed. LogService segfaults when log message pointer is overwritten Key: CELIX-189 URL: https://issues.apache.org/jira/browse/CELIX-189 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis Assignee: Alexander Broekhuis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-188) Add missing log_service headers to installations
[ https://issues.apache.org/jira/browse/CELIX-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-188. --- Resolution: Fixed Assignee: Alexander Broekhuis Add missing log_service headers to installations Key: CELIX-188 URL: https://issues.apache.org/jira/browse/CELIX-188 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis Assignee: Alexander Broekhuis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-181) Incorrect reply status when no data is returned on a remote call.
[ https://issues.apache.org/jira/browse/CELIX-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-181. --- Resolution: Duplicate Already fixed in the linked issue. Incorrect reply status when no data is returned on a remote call. - Key: CELIX-181 URL: https://issues.apache.org/jira/browse/CELIX-181 Project: Celix Issue Type: Bug Components: Remote Service Admin Reporter: Alexander Broekhuis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-115) logservice bundle entries list grows indefinitely
[ https://issues.apache.org/jira/browse/CELIX-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281891#comment-14281891 ] Alexander Broekhuis commented on CELIX-115: --- I propose to add a configuration property to specify how large this buffer should be. Besides that it might make sense (as Apache Felix does) to enable/disable debug logging. So that gives 2 properties (blatantly copied from Felix and adjusted to Celix): * CELIX_LOG_MAX_SIZE Default 100 The maximum size of the log history. A value of -1 means the log has no maximum size; a value of 0 means that no historical information is maintained * CELIX_LOG_STORE_DEBUG Default false Determines whether or not debug messages will be stored in the history logservice bundle entries list grows indefinitely - Key: CELIX-115 URL: https://issues.apache.org/jira/browse/CELIX-115 Project: Celix Issue Type: Improvement Components: Log Service Affects Versions: 1.0.0-incubating Reporter: Gabriele Ricciardi Log entries list (log-entries) grows indefinitely, since every call to log_addEntry function simply add an element to log-entries. This can be a problem on long run sessions. Maybe it should be implemented as a circular list with a fixed number of entries? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-202) Not all components are disabled with a clean build
[ https://issues.apache.org/jira/browse/CELIX-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-202. --- Resolution: Fixed Fixed. Left the Framework and Launcher as enabled. Any dependencies will be picked up automatically. Not all components are disabled with a clean build -- Key: CELIX-202 URL: https://issues.apache.org/jira/browse/CELIX-202 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis Currently several components are enabled when creating a new build. This is not convenient when using CMake in an automated process. Also, it makes sense to disable everything by default, that way a user can go in and enable only the needed parts, instead of having to disable parts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-198) Logging can segfault for strings 512 characters or longer
[ https://issues.apache.org/jira/browse/CELIX-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-198. --- Resolution: Fixed Updated the log_command to determine the length and use snprintf. --- Author: abroekhuis Date: Thu Jan 8 14:29:38 2015 New Revision: 1650294 URL: http://svn.apache.org/r1650294 Log: CELIX-198: Updated log_command to determine message length, and use snprintf to prevent overflows. Logging can segfault for strings 512 characters or longer - Key: CELIX-198 URL: https://issues.apache.org/jira/browse/CELIX-198 Project: Celix Issue Type: Bug Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating log_service/public/src/log_helper.c::logHelper_log() uses a buffer of 512 bytes and doesn't check to make sure that the buffer is long enough to hold the input string. The buffer should be increased (or dynamic memory allocation used) and the sizes should be checked to prevent overrun (perhaps by using vnsprintf() instead of vsprintf() ). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-198) Logging can segfault for strings 512 characters or longer
[ https://issues.apache.org/jira/browse/CELIX-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-198. --- Resolution: Fixed Fix Version/s: next-incubating Assignee: Alexander Broekhuis I've pushed a simple fix that increases the length to 1024 and uses vsnprintf. This should prevent segfaults. A more dynamic solution can be implemented later if needed. Is this good enough for now? Author: abroekhuis Date: Wed Jan 7 14:43:57 2015 New Revision: 1650071 URL: http://svn.apache.org/r1650071 Log: CELIX-198: Updated log_helper to use vsnprintf to prevent buffer overflows. Logging can segfault for strings 512 characters or longer - Key: CELIX-198 URL: https://issues.apache.org/jira/browse/CELIX-198 Project: Celix Issue Type: Bug Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating log_service/public/src/log_helper.c::logHelper_log() uses a buffer of 512 bytes and doesn't check to make sure that the buffer is long enough to hold the input string. The buffer should be increased (or dynamic memory allocation used) and the sizes should be checked to prevent overrun (perhaps by using vnsprintf() instead of vsprintf() ). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CELIX-200) SEGFAULT occurs when remote services are closed
[ https://issues.apache.org/jira/browse/CELIX-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis reassigned CELIX-200: - Assignee: Alexander Broekhuis SEGFAULT occurs when remote services are closed --- Key: CELIX-200 URL: https://issues.apache.org/jira/browse/CELIX-200 Project: Celix Issue Type: Improvement Components: Remote Service Admin Reporter: Daniel Parker Assignee: Alexander Broekhuis In remote_services/topology_manager/private/src/topology_manager.c::topologyManager_removeImportedService(), services are removed with hashMap_remove() rather than hashMapIterator_remove(), which can cause the iterator to get out of sync with the hashMap and SEGFAULT. Note that this doesn't cause an error if there is only a single proxy registered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-200) SEGFAULT occurs when remote services are closed
[ https://issues.apache.org/jira/browse/CELIX-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-200. --- Resolution: Fixed Fixed. --- Author: abroekhuis Date: Wed Jan 7 21:09:37 2015 New Revision: 1650164 URL: http://svn.apache.org/r1650164 Log: CELIX-200: Updated log_entry to copy the symbolic name instead of only taking the pointer. SEGFAULT occurs when remote services are closed --- Key: CELIX-200 URL: https://issues.apache.org/jira/browse/CELIX-200 Project: Celix Issue Type: Improvement Components: Remote Service Admin Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating In remote_services/topology_manager/private/src/topology_manager.c::topologyManager_removeImportedService(), services are removed with hashMap_remove() rather than hashMapIterator_remove(), which can cause the iterator to get out of sync with the hashMap and SEGFAULT. Note that this doesn't cause an error if there is only a single proxy registered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-200) SEGFAULT occurs when remote services are closed
[ https://issues.apache.org/jira/browse/CELIX-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268233#comment-14268233 ] Alexander Broekhuis commented on CELIX-200: --- I suspect this comment relates to CELIX-195? Anyway, in the log_entry, the symbolicname was not copied, which might result in an invalid pointer. SEGFAULT occurs when remote services are closed --- Key: CELIX-200 URL: https://issues.apache.org/jira/browse/CELIX-200 Project: Celix Issue Type: Improvement Components: Remote Service Admin Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating In remote_services/topology_manager/private/src/topology_manager.c::topologyManager_removeImportedService(), services are removed with hashMap_remove() rather than hashMapIterator_remove(), which can cause the iterator to get out of sync with the hashMap and SEGFAULT. Note that this doesn't cause an error if there is only a single proxy registered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-196) error message not initialized for informational framework events
[ https://issues.apache.org/jira/browse/CELIX-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268224#comment-14268224 ] Alexander Broekhuis commented on CELIX-196: --- On line 2095 request-error is set to . As far as I can tell that should be enough. Are you seeing some problems with this in usage? error message not initialized for informational framework events Key: CELIX-196 URL: https://issues.apache.org/jira/browse/CELIX-196 Project: Celix Issue Type: Bug Reporter: Daniel Parker Priority: Minor in, framework/private/src/framework.c::fw_fireFrameworkEvent(), if errorCode is CELIX_SUCCESS, then request-error is never initialized. This can result in junk data being logged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-199) Code Coverage should be optional rather than required by cmake
[ https://issues.apache.org/jira/browse/CELIX-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-199. --- Resolution: Fixed Fix Version/s: next-incubating Assignee: Alexander Broekhuis Fixed. If ok, please close. Thanks. Author: abroekhuis Date: Wed Jan 7 21:09:39 2015 New Revision: 1650165 URL: http://svn.apache.org/r1650165 Log: CELIX-199: Moved the code coverage CMake macros inside an option that can be enabled using the CMake cache (ENABLE_CODE_COVERAGE). Code Coverage should be optional rather than required by cmake -- Key: CELIX-199 URL: https://issues.apache.org/jira/browse/CELIX-199 Project: Celix Issue Type: Improvement Reporter: Daniel Parker Assignee: Alexander Broekhuis Priority: Minor Fix For: next-incubating -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-197) insufficient memory allocated
[ https://issues.apache.org/jira/browse/CELIX-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-197. --- Resolution: Fixed Fix Version/s: next-incubating Assignee: Alexander Broekhuis Fixed the issue by allocating enough memory. While the resulting value might be shorter than the incoming value, using the incoming length + 1 should always be enough. - Author: abroekhuis Date: Wed Jan 7 14:52:49 2015 New Revision: 1650075 URL: http://svn.apache.org/r1650075 Log: CELIX-197: Fixed allocation problems in filter.c. insufficient memory allocated - Key: CELIX-197 URL: https://issues.apache.org/jira/browse/CELIX-197 Project: Celix Issue Type: Bug Reporter: Daniel Parker Assignee: Alexander Broekhuis Priority: Minor Fix For: next-incubating The function framework/private/src/filter.c::filter_parseValue() uses strdup() to allocate memory rather than malloc(strlen(fileterString)) or something. Note that I haven't ever seen this actually cause problems, but the code is incorrect, so I thought I'd mention it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-195) SEGFAULT occurs when running a log command.
[ https://issues.apache.org/jira/browse/CELIX-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-195. --- Resolution: Fixed Fix Version/s: next-incubating Assignee: Alexander Broekhuis Fixed this issue by caching the symbolic name in the log entry and removing the bundle and reference pointer. If this works, please close the issue. - Author: abroekhuis Date: Wed Jan 7 18:28:30 2015 New Revision: 1650135 URL: http://svn.apache.org/r1650135 Log: CELIX-195: Updated log_entry to cache symbolic name to prevent crashes due to invalid pointers if a bundle is uninstalled. SEGFAULT occurs when running a log command. --- Key: CELIX-195 URL: https://issues.apache.org/jira/browse/CELIX-195 Project: Celix Issue Type: Bug Components: Log Service Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating If you are running the log helper in an remote service endpoint, then stop the bundle which talks to that endpoint, the bundle pointer for logs associated with that endpoint will become invalid. If you then run the 'log' command from the shell, a segfault will occur. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-200) SEGFAULT occurs when remote services are closed
[ https://issues.apache.org/jira/browse/CELIX-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-200. --- Resolution: Fixed Fix Version/s: next-incubating I've pushed a fix for this, including several other fixed related to the RSA. If this fixes the issue, can you close it? Thanks for the report! - Author: abroekhuis Date: Wed Jan 7 14:27:33 2015 New Revision: 1650066 URL: http://svn.apache.org/r1650066 Log: CELIX-200: - Fixed issue where imported endpoints are not removed properly. - Added additional proxy to the calculator for testing. - Updated installation files to include the proper/new rsa headers and code. - Updated proxy factory to copy the correct service properties to the proxy service. - Exclude EXPORTED_INTERFACES for imported proxies to prevent a loop from export - import - export - ... SEGFAULT occurs when remote services are closed --- Key: CELIX-200 URL: https://issues.apache.org/jira/browse/CELIX-200 Project: Celix Issue Type: Improvement Components: Remote Service Admin Reporter: Daniel Parker Assignee: Alexander Broekhuis Fix For: next-incubating In remote_services/topology_manager/private/src/topology_manager.c::topologyManager_removeImportedService(), services are removed with hashMap_remove() rather than hashMapIterator_remove(), which can cause the iterator to get out of sync with the hashMap and SEGFAULT. Note that this doesn't cause an error if there is only a single proxy registered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CELIX-191) Framework get stuck while stopping a bundle in STARTING state
[ https://issues.apache.org/jira/browse/CELIX-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233120#comment-14233120 ] Alexander Broekhuis commented on CELIX-191: --- Thanks for the patch, but I think the proper way to solve this is to set a bundle to STOPPED if it cannot be started. The spec says: If the start(BundleContext) method throws an exception, the Framework must mark the bundle as stopped and send out STOPPING and STOPPED events but it must not call the Bundle Activator stop(BundleContext) method. The start method must therefore be careful to clean up any resources it creates in the start method when it throws an exception. So yeah, I do see the problem, and this needs to be fixed, but the current state transitions follow the OSGi spec, although error handling is not done properly. So instead of changing the order of the states, the startBundle function needs to be updated to correctly mark a bundle as stopped and clean up resources when an error is raised. Framework get stuck while stopping a bundle in STARTING state - Key: CELIX-191 URL: https://issues.apache.org/jira/browse/CELIX-191 Project: Celix Issue Type: Bug Reporter: Gabriele Ricciardi Attachments: framework_starting_bundle.patch In case there is a bundle in STARTING state (e.g. because the bundleActivator_create is successful but the bundleActivator_start fails for some reason) and the framework stop (i.e. stop 0) is called, the whole framework enters in a tight loop and gets stuck reporting a bundle exception. Find attached a patch file -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CELIX-189) LogService segfaults when log message pointer is overwritten
Alexander Broekhuis created CELIX-189: - Summary: LogService segfaults when log message pointer is overwritten Key: CELIX-189 URL: https://issues.apache.org/jira/browse/CELIX-189 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis Assignee: Alexander Broekhuis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CELIX-188) Add missing log_service headers to installations
Alexander Broekhuis created CELIX-188: - Summary: Add missing log_service headers to installations Key: CELIX-188 URL: https://issues.apache.org/jira/browse/CELIX-188 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-156) Enable all warnings
[ https://issues.apache.org/jira/browse/CELIX-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-156. --- Resolution: Fixed Fix Version/s: next-incubating Enable all warnings --- Key: CELIX-156 URL: https://issues.apache.org/jira/browse/CELIX-156 Project: Celix Issue Type: Improvement Reporter: Alexander Broekhuis Fix For: next-incubating Currently Celix is build without reporting all warnings. To clean up the code this should be enabled. Are there more options that we want by default? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CELIX-157) service_reference misses functions to get property keys and values
[ https://issues.apache.org/jira/browse/CELIX-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Broekhuis resolved CELIX-157. --- Resolution: Fixed Fix Version/s: next-incubating service_reference misses functions to get property keys and values -- Key: CELIX-157 URL: https://issues.apache.org/jira/browse/CELIX-157 Project: Celix Issue Type: Bug Reporter: Alexander Broekhuis Fix For: next-incubating Currently, to get to the service properties, the internal structure of reference and registration is needed. To make the API cleaner private functions should be moved to the private header. Als the service_reference needs a getProperty and getPropertyKeys function. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
