Red Hat Linux 3 ES

Някой да знае или е да е имал проблеми с бъгове в malloc/free в тази версия?

sto ne probas malko po konkretno a ?

DrFrancky

Проблема е със сърверска програма която трябвяа да рабти без да крашва (разбирра се) . И всъщност си работи на сума платформи с месеци (включително RedHat AS2.1), но точно на тази крашва или в malloc/free или corе-a изобщо не се чете. По-точно чете се, но стек трейс не показва нищо. A има linenumber info, така че това не е проблема.
Мога да го оправя, но преследването на подобни бъгове глъта доста време, а не ми се гонят бъгове ако са из C библиотеките.
Та ако някой е чувал за проблем с мемори мениджъра просто исках да си спестя малко време.
Не казвам че проблема не е в нашия телевизор

Проблемът определено е във вашия телевизор. :)

Какво е обяснението за това че работи на следните платформи:
Solaris 8/9, Linux 7/8, Suse, RedHat AS2.1, HP-UX 11(itanium), Tru64 5.0/5.1,AIX 5.1
Windows-a не би трябвало да го споменавам, просто защото имплементацията на някой модулите е доста по-различна от всичко изброено, но работи и на него.
Включително и на такива екзотики като: OS390, zOS
Определено последните две са ,много "чувствителни" на тема бъгове.
Пък и само питам, ако някой знае нещо, ако не като го намеря ще ти кажа в кой телевизор е повредата

И ще ти кажа защо мисля така: кодът за управление на паметта е много чувствителен на грубиянски грешки като писане извън заделената за от заявки памет.

Така че библиотеките на ES най-вероятно са си съвсем в ред, но с някаква дреболия реализацията им се отличава от изброените от теб платформи, а точно тази дреболия се омазва от сървърния софтуер.

Ще ти кажа сладко примерче. Значи, имаме C-функцийка, в която се декларира локална променлива char a[12], след което малко по-долу в резултат от буболечка прави memset (a, 0, 16). С GCC до 3.3.6 и какви ли не дистрибуции на Linux, а даже и на SCO и Soaris - ядове няма.

Добре, обаче, аз смело решавам да подкарам софтуера, в който се намира въпросната функцийка с GCC 4.x. Познай - ефектите като твоите - core-ве, от които нищо се не вижда. Оправяш размера на масива и всичко е на шест

А, и конкретно за ES 3.0 - няма проблеми с malloc / free, използвам го на production система от доста време без ядове.

es 3 ne e s gcc 4

DrFrancky

Казвам две отделни неща - че съм се пробвал да подкарам софтуера с gcc 4 и че същият този софтуер работи без проблем с ES 3.

prosto spomenah che ES3 ne e s gcc4

DrFrancky

Щом казваш че го ползваш и няма проблеми вярвам ти до доказване на противното
Примера с масива и сетването не е проблем. В сорса е забранено ползването на магически числа.

Въх, memset без sizeof за брой елементи? Трябва да назначавате по-кадърни програмисти :)

Ами божа работа защо работи на някои места. Явно има някоя функция, която пише извън заделената памет. Скоро ми се случи да използвам функция в ядрото, която кой знае защо пише извън предоставената му памет (struct sockaddr_un) (според коментара във функцията, това не било бъг :). Дълго време всичко работеше нормално, защото локалната променлива заделена след структурата не се е използвала едновременно, така че никой не е забелязал "особеността". След разместване на декларацията на локалните променливи изведнъж ядрото започна да гърми :) Може и при вас случая да е подобен.

Какво ще кажеш за следната конструкция:

if (strncmp (buff, "MAXTOTALSIZE", 12)) token = 17;

... анализът продължава още известно време  ...

switch (token) {

...

case 17:

...



И това също не е най-лошото ...

Честно казано, аз предпочитам код като:

   if (!strncmp(s, "alabala", 7)) ...

    char *alabala = "alabala";

    ... // 100 реда код

    if (!strncmp(s, alabala, sizeof(alabala)) ...

Въпреки че при първия случай има малка вероятност за допускане на грешка при промяна на стринга, четимостта на кода е много по-добра и според мен това е по-важно. Разбира се, ако стринга трябва да се проверява на повече от едно място, или пък размера и съдържанието се използват на различни места, бих избрал друг вариант :)

А аз предпочитам да използвам готов синтактичен анализатор. Описваш си граматиката като бял човек, връчваш я на парсера - и пей сърце. После може SAX тип, може DOM - при всички случаи е и по-лесно, и по-бързо, и по-малко налазено от буби.

Между другото, във втория пример имаш грешка - използваш sizeof (alabala), вместо strlen (alabala). Виж, ако беше #define alabala "alabala", става, горе-долу (с грешка 1 )

> Между другото, във втория пример имаш грешка - използваш sizeof (alabala), вместо strlen
> (alabala). Виж, ако беше #define alabala "alabala", става, горе-долу (с грешка 1 )

Знам, нарочно пропуснах -1, да видя дали някой ще го забележи, пък и за да е по-кратък примера :)

Всъщност, в кода ми има (още една) грешка -- вместо

    char *alabala = "alabala";

да се чете

    char alabala[] = "alabala";

Оказа се че клиентите биле виновни (както обикновеено)
Всъщност проблема не е точно в malloc/free а те ползвали външна библиотека която рънвала системата out of resources (resource leek).
Както и да е проблема не е в сървера, което означава да му мислят други

Все пак имаше проблем и в malloc.
Ако някойто се интересува ето лика:
[линк]

А ето го и patch-а: [линк]