[SOLVED] Calling QString::toWCharArray causes segmentation fault
-
wrote on 26 Jun 2015, 12:04 last edited by kdev
Hi,
I've strange problem in my app: I'm getting SIGSEGV inside the instruction calling QString::toWCharArray.This is the used code:
Help::Help(QWidget *parent) : QWidget(parent), ui(new Ui::Help) { ui->setupUi(this); wchar_t __lbl[33]; QString lbl = ui->label->text(); lbl.toWCharArray(__lbl); //here the SIGSEGV bug occurs }
This is the output of the GNU debugger:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000405b30 in load<int> (_q_value=@0x3c0000003e: <error reading variable>)
at /opt/Qt5.4.2/5.4/gcc_64/include/QtCore/qgenericatomic.h:90
90 return _q_value;I'm currently unable to fix this bug.
Thanks for your help. -
wrote on 26 Jun 2015, 12:18 last edited by mcosta
Hi and welcome to devnet,
are you sure
lbl
length is less or equal to 33??from Qt docs
array has to be allocated by the caller and contain enough space to hold the complete string (allocating the array with the same length as the string is always sufficient).
-
Hi and welcome to devnet,
are you sure
lbl
length is less or equal to 33??from Qt docs
array has to be allocated by the caller and contain enough space to hold the complete string (allocating the array with the same length as the string is always sufficient).
-
wrote on 26 Jun 2015, 12:27 last edited by
Whats the length of
lbl
???I tried this program
#include <QCoreApplication> #include <QtDebug> int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); QString s = "Super Huge Long long long log string"; const int LABEL_SIZE = 100; wchar_t myLabel [LABEL_SIZE]; qDebug() << s.toWCharArray(myLabel); }
it works, if I change LABEL_SIZE to 20 it crashes.
Which platform?? I'm on OS X
-
Whats the length of
lbl
???I tried this program
#include <QCoreApplication> #include <QtDebug> int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); QString s = "Super Huge Long long long log string"; const int LABEL_SIZE = 100; wchar_t myLabel [LABEL_SIZE]; qDebug() << s.toWCharArray(myLabel); }
it works, if I change LABEL_SIZE to 20 it crashes.
Which platform?? I'm on OS X
wrote on 26 Jun 2015, 12:42 last edited by@mcosta Ah, I was misunderstanding .. I was unaware of the length of lbl which was 365: So the cause of the segmentation fault is clear here. It is not an OS problem (I'm on GNU/Linux). Changing the length of __lbl to 399 solved the problem.
Thanks. -
Why are you hardcoding the length anyway? What if you decide to use 400 characters one day? You're gonna revisit that code? Just check the length of the string before conversion and allocate enough space for it.
-
Why are you hardcoding the length anyway? What if you decide to use 400 characters one day? You're gonna revisit that code? Just check the length of the string before conversion and allocate enough space for it.
wrote on 27 Jun 2015, 08:29 last edited by kdev@Chris-Kawa Yes, that's true .. using that code instead
__lbl = (wchar_t *)calloc(this->ui->label->text().count(), sizeof(wchar_t));
for allocation is the best way. Thank you for this notice. -
Since you're using c++ I would consider using
new/delete
instead ofcalloc/free
, or, better yet, aunique_ptr
to stay safe of exception problems. Also, according to the standard, names starting with double underscores (and single underscore in global namespace) are reserved for internal compiler/stl implementation. You're stepping on enemy territory using these. -
Since you're using c++ I would consider using
new/delete
instead ofcalloc/free
, or, better yet, aunique_ptr
to stay safe of exception problems. Also, according to the standard, names starting with double underscores (and single underscore in global namespace) are reserved for internal compiler/stl implementation. You're stepping on enemy territory using these.wrote on 27 Jun 2015, 08:41 last edited by@Chris-Kawa I'm mainly a C programmer, I don't like using C++ if not for widget programming .. anyway, what does "reserved for internal compiler/stl implementation" mean?
-
anyway, what does "reserved for internal compiler/stl implementation" mean?
Means that such names are not to be used by users (us). They are reserved for compilers and STL.
For example the standard__LINE__
,__FILE__
and__func__
macros, or the vendor specific keywords like MSVC's__super
.This restriction is not enforced by any compiler I know, but technically you shouldn't name your stuff this way and implementation is free to do with that code whatever it wants (undefined behavior in user space).
-
anyway, what does "reserved for internal compiler/stl implementation" mean?
Means that such names are not to be used by users (us). They are reserved for compilers and STL.
For example the standard__LINE__
,__FILE__
and__func__
macros, or the vendor specific keywords like MSVC's__super
.This restriction is not enforced by any compiler I know, but technically you shouldn't name your stuff this way and implementation is free to do with that code whatever it wants (undefined behavior in user space).
wrote on 27 Jun 2015, 09:01 last edited by@Chris-Kawa Yes, that's true .. but I'm quite careful about that, and I have enough experience in C Programming with GNU development tools such as GCC.
-
Yeah, and I'm not saying that it will ever break. I can't imagine any compiler doing anything malicious to such code. I'm just saying it's standard non-conforming code.
1/12