Google Skupine ne podpirajo več novih objav ali naročnin v storitvi Usenet. Zgodovinsko vsebino si je še vedno mogoče ogledati.
Dismiss

malloc -> segfault linux, no segfault NetBSD

14 ogledov
Preskoči na prvo neprebrano sporočilo

Jan Schaumann

neprebran,
29. apr. 2001, 14:40:5429. 4. 01
do
Hallo,

mein Problem:

aus irgendwelchen Gruenden stoesst sich Linux and folgendem statement:

theList = malloc(256);

und liefert mir einen segfault. An anderen stellen im Programm kann ich
aber ohne weiteres malloc'en und free'n. Interessanterweise stoert sich
NetBSD ueberhaupt nicht dran (wieso auch, ist doch in Ordnung)...

Fuer jeden Hinweis dankbar,

-Jan

--
Jan Schaumann <http://www.netmeister.org>

% \(-
(-: Command not found.

Felix von Leitner

neprebran,
29. apr. 2001, 15:04:1629. 4. 01
do
Thus spake Jan Schaumann (jsch...@netmeister.org):

> aus irgendwelchen Gruenden stoesst sich Linux and folgendem statement:

> theList = malloc(256);

> und liefert mir einen segfault. An anderen stellen im Programm kann ich
> aber ohne weiteres malloc'en und free'n. Interessanterweise stoert sich
> NetBSD ueberhaupt nicht dran (wieso auch, ist doch in Ordnung)...

Dein Programm schreibt wild im Speicher herum und überschreibt dabei die
Strukturen von malloc().

Lerne, mit einem Debugger umzugehen.

Felix

Patrick Schaaf

neprebran,
29. apr. 2001, 15:06:0429. 4. 01
do
jsch...@netmeister.org (Jan Schaumann) writes:

>mein Problem:

>aus irgendwelchen Gruenden stoesst sich Linux and folgendem statement:

>theList = malloc(256);

>und liefert mir einen segfault.

Dann hast Du davor einen Fehler, in Deinem eigenen Code, der die
interne Verpointerung von malloc zerstoert. Auswirken tut sich
das dann natuerlich bei dem naechsten malloc- oder free-Aufruf.

dmalloc, electric fence, und aehnliche Libraries, werden Dir helfen,
Dich davon zu ueberzeugen, dass der Fehler Dein eigener ist.

Gruss
Patrick

Florian Weimer

neprebran,
29. apr. 2001, 16:06:5029. 4. 01
do
jsch...@netmeister.org (Jan Schaumann) writes:

> aus irgendwelchen Gruenden stoesst sich Linux and folgendem statement:
>
> theList = malloc(256);

Das bedeutet höchstwahrscheinlich, daß an diesem Punkt der Heap
bereits korrumpiert wurde. Die die unter GNU/Linux üblicherweise
GNU-Implementation von malloc() ist da sehr pingelig, mehr als bei
anderen Systemen.

Ullrich von Bassewitz

neprebran,
29. apr. 2001, 15:51:4829. 4. 01
do
Jan Schaumann <jsch...@netmeister.org> wrote:
> aus irgendwelchen Gruenden stoesst sich Linux and folgendem statement:
>
> theList = malloc(256);
>
> und liefert mir einen segfault.

Funktioniert hier einwandfrei:

---------------------------------------------------------------------
Script started on Sun Apr 29 21:43:11 2001
uz@trixie:~/tmp$ cat > t.c
#include <stdlib.h>
int main (void)
{
void* theList = malloc (256);
exit (EXIT_SUCCESS);
}
uz@trixie:~/tmp$ gcc -Wall -O2 -o t t.c
t.c: In function `main':
t.c:4: warning: unused variable `theList'
uz@trixie:~/tmp$ ./t
uz@trixie:~/tmp$ exit
exit

Script done on Sun Apr 29 21:44:18 2001
---------------------------------------------------------------------

Deine Frage ist vermutlich etwas falsch gestellt. Du machst bereits Annahmen
ueber das Problem, und deshalb hast Du wichtige Informationen einfach
weggelassen.

Wahrscheinlich ist Dein Programm wesentlich als das obige, und wahrscheinlich
finden sich darin noch mehr Aufrufe von malloc. Mit ziemlicher Sicherheit hast
Du irgendwo einen Speicher-Ueberschreiber, d.h. Du belegst Speicher und
schreibst ueber die Grenzen des reservierten Speicherblocks hinaus. Erstens
reagieren die unterschiedlichen Implementationen von malloc/free darauf
unterschiedlich (deshalb funktioniert es mit anderen Betriebssystemen),
zweitens tritt erst spaeter ein Fehler auf, naemlich dann, wenn auf den
ueberschriebenen Speicher zugegriffen wird. Der Fehler liegt also nicht an
Linux, und er liegt auch nicht an der Stelle, an der Dein Programm wegen
SIGSEGV abgebrochen wird.

Moegliche Abhilfen:

0. Das naechste Mal besser aufpassen:-)

1. Manuelle Durchsicht des Codes.

2. Die glibc hat spezielle Debugging Routinen fuer malloc/free, diese werden
durch die Environment-Variable MALLOC_CHECK_ enabled:

---------------------------------------------------------------------
Script started on Sun Apr 29 21:47:36 2001
uz@trixie:~/tmp$ cat > t.c
#include <stdlib.h>
#include <string.h>
int main (void)
{
void* theList = malloc (256);
memset (theList, 0, 257); /* <-- Fehler */
free (theList);
exit (EXIT_SUCCESS);
}
uz@trixie:~/tmp$ gcc -O2 -Wall -o t t.c
uz@trixie:~/tmp$ ./t
uz@trixie:~/tmp$ MALLOC_CHECK_=1 ./t
malloc: using debugging hooks
free(): invalid pointer 0x80496b8!
uz@trixie:~/tmp$ exit
exit

Script done on Sun Apr 29 21:48:21 2001
---------------------------------------------------------------------

3. Teure (und gute) Debugging-Tools wie Purify (normalerweise Pflicht fuer
groessere Programme).

Gruss


Uz


--
Ullrich von Bassewitz u...@musoftware.de

Jan Schaumann

neprebran,
30. apr. 2001, 00:12:5730. 4. 01
do
* Ullrich von Bassewitz schrieb:

> Wahrscheinlich ist Dein Programm wesentlich als das obige, und wahrscheinlich
> finden sich darin noch mehr Aufrufe von malloc. Mit ziemlicher Sicherheit hast
> Du irgendwo einen Speicher-Ueberschreiber, d.h. Du belegst Speicher und
> schreibst ueber die Grenzen des reservierten Speicherblocks hinaus. Erstens
> reagieren die unterschiedlichen Implementationen von malloc/free darauf
> unterschiedlich (deshalb funktioniert es mit anderen Betriebssystemen),
> zweitens tritt erst spaeter ein Fehler auf, naemlich dann, wenn auf den
> ueberschriebenen Speicher zugegriffen wird. Der Fehler liegt also nicht an
> Linux, und er liegt auch nicht an der Stelle, an der Dein Programm wegen
> SIGSEGV abgebrochen wird.

So ist es - ich hab latuernich im Speicher rumgesaut und mir mein malloc
verhauen (zumindest unter linux).

> Moegliche Abhilfen:
>
> 0. Das naechste Mal besser aufpassen:-)
>
> 1. Manuelle Durchsicht des Codes.
>
> 2. Die glibc hat spezielle Debugging Routinen fuer malloc/free, diese werden
> durch die Environment-Variable MALLOC_CHECK_ enabled:

Very cool - das kannt ich noch nicht. Dir und den anderen vielen Dank -
ich hab mein Problem dann doch noch gefunden und beheben koennen. Und
wieder was gelernt ;-)

-Jan

--
Jan Schaumann <http://www.netmeister.org>

Respect is a rational process
-- McCoy, "The Galileo Seven", stardate 2822.3

0 novih sporočil