Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. [SOLVED] Calling QString::toWCharArray causes segmentation fault
Forum Updated to NodeBB v4.3 + New Features

[SOLVED] Calling QString::toWCharArray causes segmentation fault

Scheduled Pinned Locked Moved General and Desktop
12 Posts 3 Posters 3.8k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    kdev
    wrote on 26 Jun 2015, 12:04 last edited by kdev
    #1

    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.

    1 Reply Last reply
    0
    • M Offline
      M Offline
      mcosta
      wrote on 26 Jun 2015, 12:18 last edited by mcosta
      #2

      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).

      Once your problem is solved don't forget to:

      • Mark the thread as SOLVED using the Topic Tool menu
      • Vote up the answer(s) that helped you to solve the issue

      You can embed images using (http://imgur.com/) or (http://postimage.org/)

      K 1 Reply Last reply 26 Jun 2015, 12:20
      0
      • M mcosta
        26 Jun 2015, 12:18

        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).

        K Offline
        K Offline
        kdev
        wrote on 26 Jun 2015, 12:20 last edited by
        #3

        @mcosta I tried with wchar_t __lbl[255], but the problem is the same.

        1 Reply Last reply
        0
        • M Offline
          M Offline
          mcosta
          wrote on 26 Jun 2015, 12:27 last edited by
          #4

          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

          Once your problem is solved don't forget to:

          • Mark the thread as SOLVED using the Topic Tool menu
          • Vote up the answer(s) that helped you to solve the issue

          You can embed images using (http://imgur.com/) or (http://postimage.org/)

          K 1 Reply Last reply 26 Jun 2015, 12:42
          1
          • M mcosta
            26 Jun 2015, 12:27

            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

            K Offline
            K Offline
            kdev
            wrote on 26 Jun 2015, 12:42 last edited by
            #5

            @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.

            1 Reply Last reply
            0
            • C Online
              C Online
              Chris Kawa
              Lifetime Qt Champion
              wrote on 26 Jun 2015, 17:13 last edited by
              #6

              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.

              K 1 Reply Last reply 27 Jun 2015, 08:29
              1
              • C Chris Kawa
                26 Jun 2015, 17:13

                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.

                K Offline
                K Offline
                kdev
                wrote on 27 Jun 2015, 08:29 last edited by kdev
                #7

                @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.

                1 Reply Last reply
                0
                • C Online
                  C Online
                  Chris Kawa
                  Lifetime Qt Champion
                  wrote on 27 Jun 2015, 08:34 last edited by Chris Kawa
                  #8

                  Since you're using c++ I would consider using new/delete instead of calloc/free, or, better yet, a unique_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.

                  K 1 Reply Last reply 27 Jun 2015, 08:41
                  0
                  • C Chris Kawa
                    27 Jun 2015, 08:34

                    Since you're using c++ I would consider using new/delete instead of calloc/free, or, better yet, a unique_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.

                    K Offline
                    K Offline
                    kdev
                    wrote on 27 Jun 2015, 08:41 last edited by
                    #9

                    @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?

                    1 Reply Last reply
                    0
                    • C Online
                      C Online
                      Chris Kawa
                      Lifetime Qt Champion
                      wrote on 27 Jun 2015, 08:48 last edited by Chris Kawa
                      #10

                      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).

                      K 1 Reply Last reply 27 Jun 2015, 09:01
                      0
                      • C Chris Kawa
                        27 Jun 2015, 08:48

                        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).

                        K Offline
                        K Offline
                        kdev
                        wrote on 27 Jun 2015, 09:01 last edited by
                        #11

                        @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.

                        1 Reply Last reply
                        0
                        • C Online
                          C Online
                          Chris Kawa
                          Lifetime Qt Champion
                          wrote on 27 Jun 2015, 09:04 last edited by
                          #12

                          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 Reply Last reply
                          0

                          1/12

                          26 Jun 2015, 12:04

                          • Login

                          • Login or register to search.
                          1 out of 12
                          • First post
                            1/12
                            Last post
                          0
                          • Categories
                          • Recent
                          • Tags
                          • Popular
                          • Users
                          • Groups
                          • Search
                          • Get Qt Extensions
                          • Unsolved