LINUX.ORG.RU

[C++]Причины SIGSEGV

 


0

3

Такое себе продолжение предыдущего треда. Есть в проекте класс

class Client: public QObject
{
public:
  Client(QObject* parent) : QObject(parent) {}
  ~Client() {}
...
private:
  class ClientPrivate;
  ClientPrivate *d;
};

Из конструктора и деструктора был выкинут весь код.

Наблюдается сегфолт при выполнении данного кода:

delete new Client(NULL);

Падает в деструкторе, непонятно с какого залезая в libfam.so. valgrind способен лишь констатировать смерть (т.е. находить проблемы уже в libfam, который никаким краем вызываться не должен).

Если рядом с Client определить точно такой же Client1, то, в зависимости от взаимного положения классов в коде, сегфолта может и не быть.

Подозревается повреждение памяти, но вопрос скорее теоретического плана: что нужно повредить, чтобы в однопоточном приложении в delete new Client(); фейлился деструктор? Причем фейлился еще до вызова operator delete(void*).

★★★★★

Ответ на: комментарий от anonymous

В системном программировании на С++ не силен, но если _надо_ его вернуть - зачем тогда возмущаться на С++ - это же вам, а не ему надо. И каким образом в С с этим не было проблем? В прикладном программировании я даже не знаю, где кроме аллокаторов, нужны void*. И их использование - 99.9% bad design.

ratatosk
()
Ответ на: комментарий от anonymous

ТС отлдачик не уважаете ?

Очень уважаю. Первым делом в него полез.

учите ассемблер

Давно выучил. В отладчике ходил именно по асму и в ~Client какой-то бред. Баг видимо таки злой.

Pavval ★★★★★
() автор топика
Ответ на: комментарий от Gorthauer

Госпади... да дайте ему уже помереть спокойно(((( Я туда заглядывал пару раз и местами ужасался. Код с многолетним наслоением от совершенно разных людей, разных поколений, кое как портированный на Qt4.

Я согласен закопать его прямо сейчас, только замены в kde4 пока нет. Не тулкитофоб, пробовал и другие, но не порёрли. Мне бы только этот баг починить:)

Pavval ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Оно же легко проверяется - даже в ассемблер не нужно лазить.

Я конечно сейчас пъян, но всё-таки: а как без асма?

Pavval ★★★★★
() автор топика
Ответ на: комментарий от ratatosk

Идиотский вопрос - если Client1 не фейлится (тоже потомок QObject?), что будет, если во всем kopete переименовать? Это пляски с бубном, конечно, но учитывая, что падает в какой-то левой либе - может что-то с линковкой? Правда, не представляю, как такой может быть?

Нет, простое переименование не решает. Не фейлится, если только есть два класса - но это не решение. Не надо полумер, хочу докопаться до сути:)

Pavval ★★★★★
() автор топика
Ответ на: комментарий от Pavval

>> Оно же легко проверяется - даже в ассемблер не нужно лазить.

Я конечно сейчас пъян

Воткаяд.

а как без асма?

Находишь в классе VPTR, находишь по нему VTBL, пишешь функцию дампа того и другого и вкрячиваешь ее везде. Как только дамп одного и того же экземпляра меняется, «случилась гадость» (c).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Воткаяд.

Акагорнет.

Находишь в классе VPTR, находишь по нему VTBL, пишешь функцию дампа того и другого и вкрячиваешь ее везде. Как только дамп одного и того же экземпляра меняется, «случилась гадость» (c).

Займусь возможно сегодня.

Pavval ★★★★★
() автор топика
Ответ на: комментарий от Pavval

Сравнение поведения дает то, что битый класс вызывет libfam на том месте, где нормальный вызывает ~QObject (который тоже в отдельной либе). Фактически имеем вызов не той функции - таки повреждение VPTR или VTBL.

Pavval ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>а можно всё-таки вывод valgrind сюда?

Это всё, на что был способен valgrind: http://www.linux.org.ru/jump-message.jsp?msgid=6163669&cid=6164063

Ловит саму смерть, а не причины. До этого были только тучи leakов, только они нас не интересуют.

Pavval ★★★★★
() автор топика
Ответ на: комментарий от EtherealPhantom

Он там есть, просто забыл написать.

Pavval ★★★★★
() автор топика
Ответ на: комментарий от EtherealPhantom

BTW, в libfam есть свой класс Client. Может линкуется какая-то химера?

ЕМНИП при переименовании класса баг остается. Но я перепроверю, интересная мысль.

Pavval ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.