Russian Qt Forum

QString("asdsad");

QString str("asdsad");

Может как-то связано с оптимизацией компилера? Тут как бы даже переменной то нет))
Попробуй попробовать: , не должен падать :)

ЛОЛ, но это не единственная причина. У меня вчера такое было: лечится полной переcборкой проекта и презагрузкой gdb или даже creator-a.

Падает gdb? Легко можешь повторить? Пиши багрепорт в его багтрекер(или что у него там).
А пока ищи workaround'ы.
Падения программы - достаточно серьёзная ошибка, можно ожидать что её исправят быстро.

А по теме: перед созданием QString("asdsad"); не пробовал создавать объект QApplication/QCoreApplication?

The QCoreApplication class provides an event loop for console Qt applications

#include <QtCore/QCoreApplication>
#include <QString>

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);
    QString("asdsad");
    int i=1;
}

Служба abrtd причем падение ловит, но coredump gdb не открывает - пишет ".../ccpp-1286448548-13623/coredump": not in executable format: Формат файла не распознан. При выключенном abrtd дамп не нашел, куда сваливается и сваливается ли вообще - непонятно. Хотел прицепить к посту то, что ловит abrtd, дюже большой архив - 2.5 метра. Могу выложить куда-нибудь.
Я пытался найти какие-то специфические требования qt -  к версиям gdb и прочего - не нашел.

Насчет багрепорта - пока хз, я поставил последний gdb, что есть в репозитарии к федоре 12, но есть версия и более свежая, боюсь, сюда ее уже без тотальных обновлений не прикрутишь...

Даже если баг, они едва ли будут старые версии чинить.

непонятно, при чем тут QCoreApplication...

creator 1.3.1 gdb 6.8... проблемы нету

Ну перед обращением к класам Qt неплохо бы создать объект приложения. А QCoreApplication - это консольное приложение.

как я писал выше, у меня со старым creator (< 2.0) тоже проблемы нет... интересует >=2.0

Я хз что такое "abrtd". У меня в дебиане его нету. И гуголь не охотно сознаётся. И для coredump'a он не нужен, то есть coredump можно получить и без него. И вообще твой дистрибутивный gdb по идее будет без отладочной информации. А чтобы её заиметь, нужно его собрать с отладкой. Куда dump  валится - наверное в текущий каталог под именем "core". Это можно настроить через /proc/sys/kernel/core_pattern(man 5 core).

так все же мот дело не в gdb??

может и так, но падает именно он... падает, как видно по стеку, при вызове __strlen_sse2 () из /lib/libc.so.6. Может, дело в glibc. Может, creator, хотя тогда проблема была бы более массовая... Потому спрашиваю про версии )

Если в QtCreator 2.0.1 поставить точку останова на строчку "QString...", а затем продолжить отладку (любым способом - F5,F10,F11) - появляется сообщение "Приложение остановлено, т.к. оно получило сигнал от операционной системы. Сигнал: SIGABRT Назначение: Aborted", отладка завершается. Стек:
Код:

Thread 1 (Thread 0xb7fe38e0 (LWP 17588)):
#0  0x001867f7 in __strlen_sse2 () from /lib/libc.so.6
#1  0x00de02dc in qstrlen (str=<value optimized out>) at ../../include/QtCore/../../src/corelib/tools/qbytearray.h:68
#2  QString::fromLatin1_helper (str=<value optimized out>) at /var/tmp/qt-src/src/corelib/tools/qstring.cpp:3713
#3  0x00de6f11 in QString::fromAscii_helper (str=0x8048724 "asdsad", size=134514468) at /var/tmp/qt-src/src/corelib/tools/qstring.cpp:3774
#4  0x08048621 in QString::QString (this=0xbffff788, ch=0x8048724 "asdsad") at /opt/qtsdk-2010.05/qt/include/QtCore/qstring.h:426
#5  0x080485d1 in main (argc=1, argv=0xbffff844) at main.cpp:4

[nik@nik test_gdb_crush]# gdb ./test_gdb_crush
GNU gdb (GDB) Fedora (7.0.1-50.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/nik/projects/simple/test_gdb_crush/test_gdb_crush...done.
(gdb) b main.cpp:7
Breakpoint 1 at 0x80486b9: file main.cpp, line 7.
(gdb) r
Starting program: /home/nik/projects/simple/test_gdb_crush/test_gdb_crush
[Thread debugging using libthread_db enabled]

Breakpoint 1, main (argc=1, argv=0xbffff634) at main.cpp:7
7       QString("asdsad");
Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-1.fc12.i686 glibc-2.11.1-1.i686 libgcc-4.4.2-7.fc12.i686 libstdc++-4.4.2-7.fc12.i686
(gdb) n
8       int i=1;
(gdb) n
9   }
(gdb) n
0x00913bb6 in __libc_start_main () from /lib/libc.so.6
(gdb) n
Single stepping until exit from function __libc_start_main,
which has no line number information.

Program exited normally.
(gdb)

То может падает всё-таки программа? Баг в Qt 4.7.0? Попробуй запустить без креатора. И отладиться в консольном gdb.

Я таких рекомендаций в документации не видел. Насколько понимаю, классы Qt вполне можно использовать без приложений Qt, которые предназначены для организации и обработки цикла событий.

Ну для простых хэллоувордов может и прокатит. Но если чего посложнее, мы же не вникаем в реализацию всех этих Кутешных классов, может там и события нужны.

все ок. Т.е. дело все-таки в QtCreator?

Подозреваю что у тебя 64-х битная федора (из-за функции __strlen_sse2). Может причина и в этом?

[nik@nik /]$ uname --a
Linux nik 2.6.31.5-127.fc12.i686.PAE #1 SMP Sat Nov 7 21:25:57 EST 2009 i686 i686 i386 GNU/Linux

QtCreator 2.0.1, Qt 4.7.0 (64 bit) - не падает

да нет, 32:

А вот это-то и странно. i686 - это подразумевается что я могу взять какой-нибудь первопень, поставить на него эту федору и всё будет работать(томозить, но это другой вопрос). Не так ли? С хренали есть обращения к SSE2-инструкциям, которые появились во времена Pentium'a 4? То есть, как я понимаю есть стандартная сишная функция strlen, а уже на конкретной платформе она реализуется по-разному. Если есть SSE2, как в твоём случае, то при сборке libc компилируется его поддержка и идёт в конечном итоге обращение к функции __strlen_sse2.