Thomas Bushnell BSG | 1 Oct 2009 01:02

Re: confusion tracking down memory leak

I found my leak, for those interested.  The Chicken mysql egg magically
stores results away inside mysql-query, which you must free with
mysql-free-result, even though they are unreachable once another
mysql-query has intervened.

Thomas

On Wed, 2009-09-30 at 21:11 +0200, Andreas Rottmann wrote:
> Thomas Bushnell BSG <tb <at> becket.net> writes:
> 
> > I have a memory leak in a long-running program; I can easily provoke it.
> > (It's quite complex; too complex to post here.)
> >
> > The program involves lots of FFI interfaces to Linux syscalls, and other
> > stuff.
> >
> > The memory leak is *not* in Scheme; this is verified by the fact that
> > (memory-statistics) while it's running shows bounded memory consumption.
> >
> > Yet the heap usage is growing without limit.  There's bad malloc going
> > on somewhere.  
> >
> > Are there any convenient tools to try and figure out malloc usage in
> > Chicken Scheme?
> >
> Dunno specifically about Chicken Scheme (and "convinient" ;-), but given
> the fact that your leak is in C code, you might be able to make sense
> from Valgrind[0] output -- for C/C++ this works great, usually.
> 
> [0] http://valgrind.org/
(Continue reading)

Kon Lovett | 1 Oct 2009 02:32

Re: set-file-position! only works with fixnums


On Sep 29, 2009, at 7:55 AM, John Cowan wrote:

> In the posix unit, you should be able to pass an integral flonum to
> set-file-position!  and get one back from file-position so that files
> longer than 2^31 bytes can be handled.

Thank you. It will be fixed.

>
> -- 
> A witness cannot give evidence of his           John Cowan
> age unless he can remember being born.          cowan <at> ccil.org
>  --Judge Blagden                               http://www.ccil.org/~cowan
>
>
> _______________________________________________
> Chicken-users mailing list
> Chicken-users <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/chicken-users

Best Wishes,
Kon
Thomas Bushnell BSG | 1 Oct 2009 08:16

Re: set-file-position! only works with fixnums

On Wed, 2009-09-30 at 17:32 -0700, Kon Lovett wrote:
> On Sep 29, 2009, at 7:55 AM, John Cowan wrote:
> 
> > In the posix unit, you should be able to pass an integral flonum to
> > set-file-position!  and get one back from file-position so that files
> > longer than 2^31 bytes can be handled.
> 
> Thank you. It will be fixed.

I think this is a mistake, but "fixing" it is harder than it seems.

Really, this is totally non-schemey.  

The criterion should be an exact integer, just as it is for arrays.
Instead of allowing inexact integers to be file positions, how about
extending the hierarchy to handle these cases directly?
John Cowan | 1 Oct 2009 09:27

Re: set-file-position! only works with fixnums

Thomas Bushnell BSG scripsit:

> I think this is a mistake, but "fixing" it is harder than it seems.
> 
> Really, this is totally non-schemey.  
> 
> The criterion should be an exact integer, just as it is for arrays.
> Instead of allowing inexact integers to be file positions, how about
> extending the hierarchy to handle these cases directly?

Well, in order for that to work you have to persuade Felix to incorporate
bignums in the core, and they can't be GMP bignums either because of
the licensing -- that would make Chicken as a whole GPL, and that's not
gonna happen.  Making all that happen is what is harder than it seems.

Indexing arrays with fixnums is no problem, because Chicken won't let
them be bigger than 2^24 elements anyhow, and fixnums go up to 2^32 - 1.
The sizes of files isn't under Chicken's control, but 2^53 is plenty
big enough for a long time to come.

--

-- 
It was impossible to inveigle           John Cowan <cowan <at> ccil.org>
Georg Wilhelm Friedrich Hegel           http://www.ccil.org/~cowan
Into offering the slightest apology
For his Phenomenology.                      --W. H. Auden, from "People" (1953)
John Cowan | 1 Oct 2009 17:56

chicken-install should use sudo -v

Currently when you install an egg with many dependencies using the -s
(sudo) switch, you have to wait to enter your password until the first
time chicken-install invokes sudo.  If, on detecting the -s switch,
chicken-install immediately ran "sudo -v", the password would be requested
at the top.  This variant of sudo does not run any command.

Older sudo's that don't understand -v will just report an error, and no
harm done.

--

-- 
"Repeat this until 'update-mounts -v' shows no updates.         John Cowan
You may well have to log in to particular machines, hunt down   cowan <at> ccil.org
people who still have processes running, and kill them."        www.ccil.org/~cowan
Kon Lovett | 2 Oct 2009 03:57

Re: set-file-position! only works with fixnums


On Oct 1, 2009, at 12:27 AM, John Cowan wrote:

> Thomas Bushnell BSG scripsit:
>
>> I think this is a mistake, but "fixing" it is harder than it seems.
>>
>> Really, this is totally non-schemey.
>>
>> The criterion should be an exact integer, just as it is for arrays.
>> Instead of allowing inexact integers to be file positions, how about
>> extending the hierarchy to handle these cases directly?
>
> Well, in order for that to work you have to persuade Felix to  
> incorporate
> bignums in the core, and they can't be GMP bignums either because of
> the licensing -- that would make Chicken as a whole GPL, and that's  
> not
> gonna happen.  Making all that happen is what is harder than it seems.

Possible is adding a int64_t heap type. But involves hitting every  
piece of code that any extension of the core number system would.

>
> Indexing arrays with fixnums is no problem, because Chicken won't let
> them be bigger than 2^24 elements anyhow, and fixnums go up to 2^32  
> - 1.
> The sizes of files isn't under Chicken's control, but 2^53 is plenty
> big enough for a long time to come.

(Continue reading)

John Cowan | 2 Oct 2009 06:30

Re: set-file-position! only works with fixnums

Kon Lovett scripsit:

> Possible is adding a int64_t heap type. But involves hitting every  
> piece of code that any extension of the core number system would.

Indeed.  If we're going to do that, I'd rather go with core bignums
after all, perhaps from LibTomMath (which is dedicated to the public
domain by its author), and dispose of the issue once and for all.

> Changed posixunix to use fseeko, ftello and treat lseek as taking &  
> returning an off_t. It will use the 'long' forms when  
> _POSIX_V6_ILP32_OFF32 is defined. (Only tested with MacOS 10.5)
> 
> Changed posixwin to use _fseeki64, _ftelli64 and _lseeki64.
> 
> Note: 'file-position' now ONLY returns integer flonums!

Thanks!

--

-- 
When I'm stuck in something boring              John Cowan
where reading would be impossible or            (who loves Asimov too)
rude, I often set up math problems for          cowan <at> ccil.org
myself and solve them as a way to pass          http://www.ccil.org/~cowan
the time.      --John Jenkins
Thomas Bushnell BSG | 2 Oct 2009 19:17

Re: set-file-position! only works with fixnums

On Fri, 2009-10-02 at 00:30 -0400, John Cowan wrote:
> Kon Lovett scripsit:
> 
> > Possible is adding a int64_t heap type. But involves hitting every  
> > piece of code that any extension of the core number system would.
> 
> Indeed.  If we're going to do that, I'd rather go with core bignums
> after all, perhaps from LibTomMath (which is dedicated to the public
> domain by its author), and dispose of the issue once and for all.

Something like this is surely my preference too.
Kon Lovett | 3 Oct 2009 04:12

Re: set-file-position! only works with fixnums

Hi folks,

Since I do not know the correct DLL for _ftelli64 and _fseeki64 these  
will not used in posixwin.

They are in the MinGW header but not in libmsvcrt (in libmsvcr80/90  
but, again, what DLL). Interestingly _lseeki64 is found.

Sorry,
Kon
Kon Lovett | 3 Oct 2009 04:20

Bignums in core


On Oct 2, 2009, at 10:17 AM, Thomas Bushnell BSG wrote:

> On Fri, 2009-10-02 at 00:30 -0400, John Cowan wrote:
>> Kon Lovett scripsit:
>>
>>> Possible is adding a int64_t heap type. But involves hitting every
>>> piece of code that any extension of the core number system would.
>>
>> Indeed.  If we're going to do that, I'd rather go with core bignums
>> after all, perhaps from LibTomMath (which is dedicated to the public
>> domain by its author), and dispose of the issue once and for all.
>
> Something like this is surely my preference too.

Not sure what is desired. I am guessing the full numeric tower is the  
real concern. If only large-ish integers then the current use of  
integer flonum limit of +-9007199254740992 should be good for awhile.

>
>

Best Wishes,
Kon

Gmane