| Summary: | libloc produces memory leaks ( in perl interface ) | ||
|---|---|---|---|
| Product: | Location Database | Reporter: | Bernhard Bitsch <bbitsch> |
| Component: | libloc | Assignee: | Stefan Schantl <stefan.schantl> |
| Status: | CLOSED FIXED | QA Contact: | Peter Müller <peter.mueller> |
| Severity: | Crash | ||
| Priority: | Will affect an average number of users | CC: | agcanum, michael.tremer, m_kaya13, rolf |
| Version: | unspecified | ||
| Hardware: | i686 | ||
| OS: | Unspecified | ||
| Attachments: | a temporary work-around ( /var/ipfire/location-functions.pl ) | ||
Created attachment 792 [details]
a temporary work-around
( /var/ipfire/location-functions.pl )
(In reply to Bernhard Bitsch from comment #1) > Created attachment 792 [details] > a temporary work-around Bebima, you should absolutely post these things as a patch to the list. Attaching a changed file does not help because the changes cannot be seen without downloading the file, finding the correct version you used and changed, and nobody can reply to this. You can avoid generating double work and get bugs fixed quicker. I am increasing the priority of this ticket, because it seems to affect a large-is number of users and it crashes using the firewall GUI. *** Bug 12526 has been marked as a duplicate of this bug. *** *** Bug 12517 has been marked as a duplicate of this bug. *** (In reply to Michael Tremer from comment #2) > (In reply to Bernhard Bitsch from comment #1) > > Created attachment 792 [details] > > a temporary work-around > > Bebima, you should absolutely post these things as a patch to the list. > Attaching a changed file does not help because the changes cannot be seen > without downloading the file, finding the correct version you used and > changed, and nobody can reply to this. Michael, I have described the bug as deep as I could do, without reading the whole source of the sources affected. I did not find the real error. Thus I cannot send a patch to correct it. What I did is a workaround to survive 'til the issue is corrected. I posted it here for all affected users. It is just easier to cite the bugzilla ticket than repost the work-around every time an user reports this or similiar errors in the community. The cause of the issue seems to be a memory leak ( as far as I can see ), my changed script ( /var/ipfire/location-functions.pl of core 151 ) reduces the init() calls and thus the memory usage. - Bernhard (In reply to Bernhard Bitsch from comment #5) > Michael, I have described the bug as deep as I could do, without reading the > whole source of the sources affected. I did not find the real error. Thus I > cannot send a patch to correct it. This is an assumption, but isn't a workaround already a good solution? The final solution would indeed be what you implemented there. The software itself is not buggy. Some functions are just being called at the wrong time. > What I did is a workaround to survive 'til the issue is corrected. Which could have been shipped to users already. Workarounds are acceptable. Obviously if there is a better solution possible, it would be worth shipping that, too. > I posted it here for all affected users. It is just easier to cite the > bugzilla ticket than repost the work-around every time an user reports this > or similiar errors in the community. The is a bug *tracker*. It tracks the status of things. It is not a place for discussion about proposed patches. It is as simple as that. I would also *strongly* discourage any user from applying random patches. This is not specifically about this patch, but we have loads of people posting their own software, which will never be patched on Community and people basically ruin their firewalls. We might even consider to ban these users at some point. It is simply dangerous for people to install random software if they do not know what they are doing. I've used now some time my 'work-around' as the patches Stephan posted in the devel list. It works. This for the records. Thank you for testing & letting us know. I consider this the solution and not only a work-around. Resetting this back to ASSIGNED since a bug is MODIFIED only as soon as some commits made it into a repository (please see https://wiki.ipfire.org/devel/bugzilla/workflow for details on this). Anyway, the patchset in question is tracked here: https://patchwork.ipfire.org/project/ipfire/list/?series=1594 And here are the related commits into the ipfire-2.x repository: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=b62d7e0cc71cc1ff23d66dd8baf0f5f3c5c7a29b https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=f46fd078148d4c6959e7ab3c52f1911bd8fea9a6 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=07e42be9783ddfe2c6e49d98676fcdb7f2dfecd7 Setting this to MODIFIED... *** Bug 12542 has been marked as a duplicate of this bug. *** I can confirm that the work-around solves the problem I had with creating new firewall rules (tried with core 152) Great. Thank you for your feedback. |
Using "small" HW for IPfire ( ALIX ), I noticed odd behaviour in the WUI ( location-block.cgi ). There were listed only first ~70 countries. Enabling the debug output showed "database file ... can not be read". Analyzing the permissions and updating the database didn't help. For investigation of the problem I just copied the beginning of the .cgi to a separate perl script and changed it just to print lines of country codes and names. This script also threw the error, but before there was an error "libloc: loc_database_free: Could not unmap network nodes section: Invalid argument". First I thought of a "usual" memory limitation error of my system. Further investigations about the source location where the error is generated showed, my limitations only raised the probability of the error. What I've found exactly: - most functions in perl module location-functions call init() first. - there is no "deinit" called/processed. - this leaves the amount of the database handle I haven't found (yet) the reason for this situation, neither the reason for the loc_database_free error. Maybe it is urged by the memory management of perl/perl_XS or by the C libloc functions. What I've done so far: - I reduced the init() calls in location-functions to one. The database handle is a variable of the module, which is initialised by a call to init() with 'require "${General::swroot}/location-functions.pl";'. - all functions use this module wide handle. - this doesn't cure the missing 'deinit', but the memory block for the handle is allocated only once in the program. The memory block is deallocated with normal program end. Hope this helps for deeper investigations.