Re: Implementierung von malloc und free unter FreeBSD

From: Simon 'corecode' Schubert <corecode(at)fs.ei.tum.de>
Date: Fri, 10 Sep 2004 13:41:04 +0200

On 10.09.2004, at 11:49, Oliver Boris Fischer wrote:

> Gott, ich habe hier drei Tage an einem für mich unerklärlichen
> C-Problem geknobelt, bis ich bemerkte, daß free(p) den Speicher, auf
> den p zeigt, wahrscheinlich freigibt, jedoch die Daten, die in diesem
> Speicher abgelegt sind, unverändert läßt. Arbeite greife ich später
> wieder auf p zu, erhalte ich die Daten, die vor dem Aufruf von free()
> dort abgelegt waren. Daher zwei Fragen:
>
> 1. Ist eigentlich irgendwo festgelegt, was free mit dem Speicher,
> auf den p verweist, zu tun hat? (Natürlich außer ihn als
> frei zu markieren.)

nein, nicht dass ich wuesste. mit debugging an machen viele
implementationen ein 0xdeadbeef oder 0xdeadc0de draus, oder so was
aehnliches. das ist in *gewisser* weise ein problem, da dadurch (wie
auch durch das beibehalten des urspruenglichen inhalts) eine im release
build nicht existierende konsistenz gegeben ist... im debug build
funktionieren nachtraegliche zugriffe (zufaellig aufgrund der
konsistenz), im release nicht...

> 2. Stellt diese Standardeinstellung nicht ein Sicherheitsloch dar?

nein? warum? der speicher "gehoert" doch dem prozess, auch wenn er
gefree()t wurde. erst wenn er wieder als freier speicher (brk()?) an
den kernel zurueckwandert, muss vorsichtig damit umgegangen werden
(d.h. bei erneuter auslieferung zu loeschen)

unter linux gibt es ein wunderhuebsches program, diese art von fehlern
zu debuggen. neben einem compiler wohl das nuetzlichste werkzeug fuer
einen entwickler (vor gdb!): valgrind. gibts das eigentlich auch fuer
BSD und warum nicht?

gruesse
   simon

-- 
/"\
\ /
  \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 10 Sep 2004 - 13:41:43 CEST

search this site