[fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
Very recently fossil_getenv function was introduced as a wrapper
around standard getenv to get Unicode right.
In file.c:
/*
** Return the value of an environment variable as UTF8.
*/
char *fossil_getenv(const char *zName){
char *zValue = getenv(zName);
#ifdef _WIN32
if( zValue ) zValue = fossil_mbcs_to_utf8(zValue);
#endif
return zValue;
}
In Unix it returns pointer pointing into actual environment (should
not be modified or deallocated). In Windows, on the other hand,
fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory
is not and cannot not be freed because of UNIX behavior.
It results in memory leak on Windows. Should one care?
--Leo--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
On Thu, Feb 16, 2012 at 06:37:49AM -0500, Leo Razoumov wrote: In Unix it returns pointer pointing into actual environment (should not be modified or deallocated). In Windows, on the other hand, fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory is not and cannot not be freed because of UNIX behavior. It results in memory leak on Windows. Should one care? I think the general approach in fossil is to have short-lived processes, where those kind of leaks that don't represent relevant memory usage be freed together with the process end. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
2012/2/16 Lluís Batlle i Rossell vi...@viric.name: On Thu, Feb 16, 2012 at 06:37:49AM -0500, Leo Razoumov wrote: In Unix it returns pointer pointing into actual environment (should not be modified or deallocated). In Windows, on the other hand, fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory is not and cannot not be freed because of UNIX behavior. It results in memory leak on Windows. Should one care? I think the general approach in fossil is to have short-lived processes, where those kind of leaks that don't represent relevant memory usage be freed together with the process end. Not really. Fossil is often run as a web-server fossil ui or fossil server and can live for months at a time. And preventing memory leaks is a good software practice regardless. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
On Thu, Feb 16, 2012 at 07:09:22AM -0500, Leo Razoumov wrote: 2012/2/16 Lluís Batlle i Rossell vi...@viric.name: On Thu, Feb 16, 2012 at 06:37:49AM -0500, Leo Razoumov wrote: In Unix it returns pointer pointing into actual environment (should not be modified or deallocated). In Windows, on the other hand, fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory is not and cannot not be freed because of UNIX behavior. It results in memory leak on Windows. Should one care? I think the general approach in fossil is to have short-lived processes, where those kind of leaks that don't represent relevant memory usage be freed together with the process end. Not really. Fossil is often run as a web-server fossil ui or fossil server and can live for months at a time. And preventing memory leaks is a good software practice regardless. It forks for every request. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
2012/2/16 Lluís Batlle i Rossell vi...@viric.name: On Thu, Feb 16, 2012 at 07:09:22AM -0500, Leo Razoumov wrote: 2012/2/16 Lluís Batlle i Rossell vi...@viric.name: On Thu, Feb 16, 2012 at 06:37:49AM -0500, Leo Razoumov wrote: In Unix it returns pointer pointing into actual environment (should not be modified or deallocated). In Windows, on the other hand, fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory is not and cannot not be freed because of UNIX behavior. It results in memory leak on Windows. Should one care? I think the general approach in fossil is to have short-lived processes, where those kind of leaks that don't represent relevant memory usage be freed together with the process end. Not really. Fossil is often run as a web-server fossil ui or fossil server and can live for months at a time. And preventing memory leaks is a good software practice regardless. It forks for every request. True. In any case, in the end of the day it is Richard's call. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
On Thu, Feb 16, 2012 at 6:37 AM, Leo Razoumov slonik...@gmail.com wrote:
Very recently fossil_getenv function was introduced as a wrapper
around standard getenv to get Unicode right.
In file.c:
/*
** Return the value of an environment variable as UTF8.
*/
char *fossil_getenv(const char *zName){
char *zValue = getenv(zName);
#ifdef _WIN32
if( zValue ) zValue = fossil_mbcs_to_utf8(zValue);
#endif
return zValue;
}
In Unix it returns pointer pointing into actual environment (should
not be modified or deallocated). In Windows, on the other hand,
fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory
is not and cannot not be freed because of UNIX behavior.
It results in memory leak on Windows. Should one care?
No, one should not care.
Recall that the processing model for Fossil is that each invocation does
one operation then quits, allowing the operating system to clean up
afterwards. (The OS is your garbage collector.) It is important to free
memory that is allocated in a loop or that might be allocated multiple
times based on the size of your repository or the nature of your request.
However, for things like getenv() which are only called a small number of
times, a finite number of times, and which don't use much memory to begin
with, trying to keep track of when to free things merely increases the code
complexity and risks introducing new bugs.
--Leo--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
In ui or server commands, I guess atleast 1 instance of fossil keeps running,
listening to the port. If that functionality has memory leak, it needs a fix.
- Original Message -
From: Richard Hipp
Sent: 02/16/12 06:04 PM
To: slonik...@gmail.com, Fossil SCM user's discussion
Subject: Re: [fossil-users] memory leak using fossil_getenv and
fossil_mbcs_to_utf8
On Thu, Feb 16, 2012 at 6:37 AM, Leo Razoumov slonik...@gmail.com wrote:
Very recently fossil_getenv function was introduced as a wrapper
around standard getenv to get Unicode right.
In file.c:
/*
** Return the value of an environment variable as UTF8.
*/
char *fossil_getenv(const char *zName){
char *zValue = getenv(zName);
#ifdef _WIN32
if( zValue ) zValue = fossil_mbcs_to_utf8(zValue);
#endif
return zValue;
}
In Unix it returns pointer pointing into actual environment (should
not be modified or deallocated). In Windows, on the other hand,
fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory
is not and cannot not be freed because of UNIX behavior.
It results in memory leak on Windows. Should one care?
No, one should not care.
Recall that the processing model for Fossil is that each invocation does
one operation then quits, allowing the operating system to clean up
afterwards. (The OS is your garbage collector.) It is important to free
memory that is allocated in a loop or that might be allocated multiple
times based on the size of your repository or the nature of your request.
However, for things like getenv() which are only called a small number of
times, a finite number of times, and which don't use much memory to begin
with, trying to keep track of when to free things merely increases the code
complexity and risks introducing new bugs.
--Leo--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] memory leak using fossil_getenv and fossil_mbcs_to_utf8
On Thu, Feb 16, 2012 at 9:33 AM, altufa...@mail.com wrote:
In ui or server commands, I guess atleast 1 instance of fossil keeps
running, listening to the port. If that functionality has memory leak, it
needs a fix.
Fossil launches a separate process to handle each HTTP request. Always.
Even using the ui and server commands.
- Original Message -
From: Richard Hipp
Sent: 02/16/12 06:04 PM
To: slonik...@gmail.com, Fossil SCM user's discussion
Subject: Re: [fossil-users] memory leak using fossil_getenv and
fossil_mbcs_to_utf8
On Thu, Feb 16, 2012 at 6:37 AM, Leo Razoumov slonik...@gmail.com
wrote:
Very recently fossil_getenv function was introduced as a wrapper
around standard getenv to get Unicode right.
In file.c:
/*
** Return the value of an environment variable as UTF8.
*/
char *fossil_getenv(const char *zName){
char *zValue = getenv(zName);
#ifdef _WIN32
if( zValue ) zValue = fossil_mbcs_to_utf8(zValue);
#endif
return zValue;
}
In Unix it returns pointer pointing into actual environment (should
not be modified or deallocated). In Windows, on the other hand,
fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory
is not and cannot not be freed because of UNIX behavior.
It results in memory leak on Windows. Should one care?
No, one should not care.
Recall that the processing model for Fossil is that each invocation does
one operation then quits, allowing the operating system to clean up
afterwards. (The OS is your garbage collector.) It is important to free
memory that is allocated in a loop or that might be allocated multiple
times based on the size of your repository or the nature of your request.
However, for things like getenv() which are only called a small number of
times, a finite number of times, and which don't use much memory to begin
with, trying to keep track of when to free things merely increases the
code
complexity and risks introducing new bugs.
--Leo--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
