Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    [SOLVED] malloc fails after calling getOpenFileNames() with native file dialog

    General and Desktop
    qt5.5 qfiledialog windows
    4
    8
    2680
    Loading More Posts
    • 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.
    • S
      stefanq last edited by stefanq

      I'd like your help please, with a huge memory allocation that fails after calling getOpenFileNames(), but works if I do the same using the non-native Qt file dialog. Here's the shortest piece of code that generates a runtime error, because 400 MBytes could not be allocated:

      #include <QApplication>
      #include <QFileDialog>
      
      int main(int argc, char *argv[])
      {
          QApplication a(argc, argv);
          QStringList files = QFileDialog::getOpenFileNames();
          char* x = new char[4*100*1000000];   // allocate 400MB
          return 0;
      }
      

      I know that asking for a contiguous block of 400 MB is almost a bug in itself. However, the allocation succeeds if I either

      1. Don't call the getOpenFileNames() at all
      2. Call getOpenFileNames() with the QFileDialog:DontUseNativeDialog option

      Question: Is there a way to use the Windows native file dialog and make the 400MB allocation succeed afterwards?

      Notes:

      1. I cannot allocate before calling the file dialog, as the size of the allocation depends on the file(s) selected.
      2. Smaller allocations work, e.g. 100MB.
      3. I'm on Qt 5.5, Windows 7 64bit, the application is 32bit, mingw.
      mrjj 1 Reply Last reply Reply Quote 0
      • Jeroentjehome
        Jeroentjehome last edited by

        Hi,
        You probably use up your entire stack/heap memory allocated to your program. Increase it if you need more memory. Calling native dialogs might just allocate less memory and thus leave you room to allocate the insane char buffer.

        Greetz, Jeroen

        S 1 Reply Last reply Reply Quote 0
        • mrjj
          mrjj Lifetime Qt Champion @stefanq last edited by

          Hi and welcome
          a 32bit program on windows can max get 2GB default.
          I guess the QFileDialog::getOpenFileNames() fragments memory a bit so
          after the call, it is not possible to get contiguous block of 400 MB.
          You could try with
          QMAKE_LFLAGS += -Wl,--large-address-aware
          and see if that allows you to get the block.
          (note: never tried that wingw)

          Can I ask why you need such huge buffer?

          S 1 Reply Last reply Reply Quote 1
          • A
            alex_malyu last edited by alex_malyu

            Working with arrays of size so close to available memory for the process requires custom memory management. Which always is expensive in terms of efforts required.
            And there are always files which are not going to fit anyway,
            I would rather invest in handling files by parts.

            S 1 Reply Last reply Reply Quote 0
            • S
              stefanq @mrjj last edited by

              @mrjj
              Hi, thank you for your response. The --large-address-aware linker option has fixed the issue for me. I understand my process now has 3GB of useable memory. This seems to be sufficient to allocate 400MB, even after the file dialog has probably fragmented the memory. I can now allocate even 800+ MB.

              I might still decide to avoid the native file dialog.

              The huge buffer is for loading a huge image, which is then transferred as one chunk into GPU texture memory for display. This will obviously not work on every PC. As other people have suggested, the correct solution is to avoid such a large alloc. The code is just that way at the moment.

              mrjj 1 Reply Last reply Reply Quote 0
              • S
                stefanq @Jeroentjehome last edited by

                @Jeroentjehome Hi, thanks for your reply, increasing memory by using --large-address-aware has worked around my problem.

                1 Reply Last reply Reply Quote 0
                • S
                  stefanq @alex_malyu last edited by

                  @alex_malyu Hi and thanks for replying, you're of course correct with your suggestion for better handling of that huge file. This will have to wait, though...

                  1 Reply Last reply Reply Quote 0
                  • mrjj
                    mrjj Lifetime Qt Champion @stefanq last edited by

                    @stefanq
                    Super.
                    Thank you for the feedback.
                    Was not sure the linker flag would work with mingw.

                    That is one mother of a texture :)

                    Good luck

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post