Re: [GNUnet-developers] Some small patches

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 07 January 2004 04:58 am, Hendrik Pagenhardt wrote:
> cvs server: Diffing src/applications/afs/tools
> Index: src/applications/afs/tools/gnunet-insert.c
> ===================================================================
> RCS file:
> /var/cvs/GNUnet/GNUnet/src/applications/afs/tools/gnunet-insert.c,v
> retrieving revision 1.85
> diff -r1.85 gnunet-insert.c
> 38c38
> <     printf("%8u of %8u bytes inserted\n",
> ---
>
> >     printf("%8u of %8u bytes inserted\r",
>
> This allows using the -V option with gnunet-insert without cluttering
> the screen with progress messages...

Probably a good idea (applied).

> As I looked through the sources I saw a few places where MALLOCs were
> used for temporary variables (string buffers etc.). The only reasons I
> can imagine for doing so are:
> - replacing buffer overflows on the stack by corruptions in the heap,
> which are harder to exploit successfully (not really a good reason)
> - maximum stack size is reduced during runtime (should not be that big
> a problem)
>
> If I haven't overlooked another justification for this, I think it would
> be better to replace those MALLOCs by stack allocations wherever
> possible. It speeds things up a little, removes possible memory leaks,
> and reduces heap fragmentation.

The reason is to minimize the stack size -- or better, make it predictable and 
small.  GNUnet is using lots of threads, and a stack overflow on thread 
stacks has horrible consequences on some systems (segfault) -- and happens 
easily with a default size of 1k.  Now, we specify a larger stack when we 
create a thread, but given GNUnet's sometimes rather long call-sequences, it 
is quite difficult to get a good estimate -- and just saying 200k would be 
quite wasteful.  So the policy is roughly to MALLOC everything above 64 
bytes.

Speed is not an issue (really, GNUnet's CPU performance is dominated by 
knapsack solving and then after a while public-key crypto, but you can't 
really measure the MALLOC cost), memory leaks are easily found with valgrind 
and modern malloc implementations do not really have issues with heap 
fragmentation, especially not considering the allocation behavior of GNUnet, 
so no worries there.

Given the choice between debugging a spurious, rare segfault without 
stack-trace (corrupt!) under BSD due to a stack overflow and finding a leak 
with valgrind, I go for valgrind any day...

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE//b909tNtMeXQLkIRAkVlAJwKGwwW1EQVRHyJRSlQMWH9ERvwRQCeP3U9
p5XcP7bHa8BSwsbrdotV8GU=
=LFVg
-----END PGP SIGNATURE-----