… halde
Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Aufgabe 4
Habt ihr bei euren Lösungen auch das Problem das realloc sich beschwert das das +18te oder so realloc fehlschlägt? Alle Tests funzen nur realloc will nicht so wie geplant. :wand:
Mein Loesung und die libc beschweren sich nicht. 
Ich denke einfach dass Deine realloc Loesung noch einen
Fehler hat. Am besten Du startest alles in einem Debugger
z.b. ddd ./memstress und schaust nach was passiert. Da
kann ja auf die Test-Funktion einen break-point setzen.
Rat mal was wir schon die ganze Zeit gemacht haben …
Was fällt euch zu folgender Fehlermeldung ein?
Unter Linux:
usr/lib/gcc-lib/i486-linux/3.3.5/…/…/…/crt1.o(.text+0x18): In function _start': ../sysdeps/i386/elf/start.S:98: undefined reference to main’
collect2: ld returned 1 exit status
Unter Cygwin:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/…/…/…/libcygwin.a(libcmain.o):: undefined reference to `_WinMain@16’
collect2: ld returned 1 exit status
ne frage - gibts ein Windows-Äquivalent zu sbrk?
Wie ist denn dein Compileraufruf? Versuchst du deine halde.c als “normales”
Programm zu compilieren? Das geht nicht, weil es in deiner halde.c keine
main Funktion gibt, der Linker sucht aber danach.
:wand:
Klar stimmt. Mit bug.c oder dergleichen compilieren …
:-/ hat jemand von euch sowas gesehen?
lotec@linux-6c6j:~/Halde/Transfer> make
gcc -ansi -g -pedantic -Wall -Werror -D_XOPEN_SOURCE=500 -c halde.c
gcc -ansi -g -pedantic -Wall -Werror -D_XOPEN_SOURCE=500 -o bug bug.c halde.o
gcc -ansi -g -pedantic -Wall -Werror -D_XOPEN_SOURCE=500 -c memstress.c
cc1: warnings being treated as errors
memstress.c: In function ‘pattern_test’:
memstress.c:174: warning: cast from pointer to integer of different size
memstress.c:174: warning: cast from pointer to integer of different size
memstress.c:174: warning: cast from pointer to integer of different size
memstress.c:174: warning: cast from pointer to integer of different size
make: *** [memstress.o] Fehler 1
Es könnte sein, dass du das Programm auf einem 64-Bit-System kompilieren willst. An der entsprechenden Stelle in [m]memstress.c[/m] werden Zeiger in 32-Bit-Ganzzahlen ([m]int[/m]s) gecastet. Auf einem 64-Bit-System haben Zeiger allerdings die doppelte Größe, also 64 Bit, und lassen sich deswegen nicht anstandslos in eine 32 Bit kleine Zahl casten.
Im CIP in der 32-Bit-Umgebung müsste das Programm aber ohne Probleme kompilierbar sein.
in der Tat!
wenn du auf 64 bit arbeiten willst, kannst du die pointer in long ints oder so casten, dann kompilierts auch.
Und um die Frage zu beantworten: Ja, ich hab das auch schon gesehen.
Die memstress.c ist sowieso ein Paradebeispiel wie mans nicht machen soll fürcht ich…
bug.c
Hat sich sonst wer schon mal bug.c angeschaut.
Das ist ja richtiggehend niedlich.
jo hab sie mir schon angeguggt, also ich brauch da glaub ich kein debugger um da die fehler, va. bzgl. der speicherverwaltung, zu finden. 
Könnten fünf Fehler in der bug.c stimmen?
Edit:
Mir ist grad die überraschende Eingebung gekommen, dass man’s ja prinzipiell auch einfach ausprobieren könnte… (Oje… ich werd alt…)
Und jetzt behaupte ich mal, fünf stimmt, weil zumindest gdb und efence scheinen mittlerweile recht glücklich zu sein.
Ich finde sechs.
Einen Fehler zaehle ich doppelt, weil die Adresse auch zwei mal verwendet wird.
kann es sein dass der richtwert beim maximalen blocktest nich stimmt?
zumindestens so wie memstress.c programmiert ist…
maximaler blocktest:
c=MAX_HEAP_SIZE+64 = 1048640
versuche größer als heapsize zu schreiben-> error
c-64
genau heapsize->error(da ja verwaltungsstruktur drin liegt)
dann block anlegen: mit size = 1048512
block wird gefreet
so, c is nun 1048512+64 = 1048576
versuche anzulegen-> error, da kein so grosser zusammenhängender block verfügbar
so oft c-- , bis c < 1048512-8(fuer verwaltungsstruktur) = 1048504
–>maximaler block ist 1048504!
Der Test ist zwar nicht von mir aber fuer mich sieht es folgendermassen aus:
C beginnt bei 1048640
Erstmals erfolgreich bei -2*64 = 1048512
Jetzt wird der block allokiert, freigegeben, und c um 63 erhoeht,
c ist also nun 1048575
Davon werden jetzt einzelne Bytes abgezogen bis die allokation erfolgreich ist, was bei 1048575-7 = 1048568 der fall sein sollte,
also der Heap Groesse - 8 byte fuer die struktur. Das ist genau der Richtwert.
Dafür müsste man aber die freien Blöcke wieder zusammenfassen, was in der Aufgabenstellung (wie ich inzwischen auch mitgekriegt hab… grummel) eigentlich nicht verlangt ist…
richtig soweit hab ich natuerlich nicht gedacht aber dann sollte der malloc doch wieder bei 1048512 erfolgreich sein und nicht erst 8 byte drunter. Den Sinn der inneren Schleife verstehe ich dann allerdings auch nicht. Aber den kennt wohl nur der Schreiber des Tests [Johannes]