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] Memory (de)allocation within slots and public functions
Forum Updated to NodeBB v4.3 + New Features

[Solved] Memory (de)allocation within slots and public functions

Scheduled Pinned Locked Moved General and Desktop
5 Posts 2 Posters 2.1k Views 1 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.
  • V Offline
    V Offline
    VikMorroHun
    wrote on last edited by
    #1

    Hi!

    I have a form which has some buttons on it. Let's say I press ButtonA which clicked() signal is connected to its on_buttonA_clicked() slot. In this slot some memory is allocated with calloc() then deallocated with free(). Program works fine. But if I call a public member function from here (and I'd like to) called function1() and I put free() into this function, the program becomes unstable, crashes at exit. Clearly the cause of this behaviour is that free() cannot recognize the public variable I'm using. Is there a way to make this bug-free?

    Here is a sample class:
    @
    #ifndef WIDGET_H
    #define WIDGET_H

    #include <QWidget>

    namespace Ui {
    class Widget;
    }

    class Widget : public QWidget
    {
    Q_OBJECT

    public:
    explicit Widget(QWidget *parent = 0);
    void function1();
    char *pchar; //to allocate a char array on the heap
    ~Widget();

    private slots:
    void on_buttonA_clicked();

    private:
    Ui::Widget *ui;
    };

    #endif // WIDGET_H
    @

    1 Reply Last reply
    0
    • M Offline
      M Offline
      mlong
      wrote on last edited by
      #2

      I won't go into commentary on your design, except to say that I feel strongly that it's mostly likely a series of poor choices (using calloc rather than new, using character arrays instead of Qt's native container classes, etc.) and should probably be written to be more C++-like rather than C-like.

      However, with that briefly said:

      Make sure you always initialize your pointers to 0 initially.

      If you call free on a pointer, be sure and set it's value to 0. If you try to free memory twice, you'll have a bad time. Calling free() on a null pointer is harmless.

      Software Engineer
      My views and opinions do not necessarily reflect those of anyone -- living or dead, real or fictional -- in this universe or any other similar multiverse node. Void where prohibited. Your mileage may vary. Caveat emptor.

      1 Reply Last reply
      0
      • V Offline
        V Offline
        VikMorroHun
        wrote on last edited by
        #3

        It seems the problem occurs with a more complex data structure:

        @
        struct rek {
        QByteArray ID, Offset;
        unsigned int length;
        bool trans;
        char * string;
        };
        rek * record;

        void Widget::function1() {
        QMessageBox::information(this, tr("Ok."), record[0].string);
        }

        void Widget::on_buttonA_clicked() {
        rek * record=new rek[20]; //let's assume allocation was successful
        record[0].string=(char *)calloc(1000,sizeof(char)); //detto
        strcpy(record[0].string,"some text...");
        QMessageBox::information(this, tr("Ok."), record[0].string); //"some text..." appear in a messagebox
        function1(); //empty string or garbage appear in a messagebox - data structure unavailable, trying to free() it causes crash
        }
        @

        I'm not sure what would be more C++ like code, so if you could tell me I would be thankful. On the other hand I have to handle non-latin characters which are not stored in Unicode format so it seemed appropriate to stick to the old character arrays and string functions to prevent data loss.

        1 Reply Last reply
        0
        • M Offline
          M Offline
          mlong
          wrote on last edited by
          #4

          You're redeclaring @rek *record@ in line 14, which is masking the declaration at line 7.

          Software Engineer
          My views and opinions do not necessarily reflect those of anyone -- living or dead, real or fictional -- in this universe or any other similar multiverse node. Void where prohibited. Your mileage may vary. Caveat emptor.

          1 Reply Last reply
          0
          • V Offline
            V Offline
            VikMorroHun
            wrote on last edited by
            #5

            Thank you very much. Now I can use the debugger again. It couldn't handle this line, but it didn't tell me what the problem was either.

            1 Reply Last reply
            0

            • Login

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