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. Help... Ongoing heap corruption issue and question about main(...)
Qt 6.11 is out! See what's new in the release blog

Help... Ongoing heap corruption issue and question about main(...)

Scheduled Pinned Locked Moved General and Desktop
3 Posts 1 Posters 1.5k 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.
  • P Offline
    P Offline
    primem0ver
    wrote on last edited by
    #1

    I have had numerous issues with heap corruption in my program all revolving around using a QTcpSocket to send login data. My most recent post regarding the matter (found "here":http://qt-project.org/forums/viewthread/47597/) was resolved by using a different approach that read the data a byte at a time rather than the entire array. However, no matter how I read the object, I cannot abort or close the socket without running into the same crash that QTcpSocket.readAll() was doing. I get a "User Breakpoint" in dbgheap.c. (Method: _CrtIsValidHeapPointer(const void * pUserData)

    I am wondering if the fact that the QByteArray being sent is created in main() has anything to do with it (using the new keyword). Does the main() method, the QMainWindow, and QApplication objects all share the same heap? or does the main() method use its own heap for anything created with the new keyword? Do namespaces have anything to do with it? Do namespaces each have their own heap?

    1 Reply Last reply
    0
    • P Offline
      P Offline
      primem0ver
      wrote on last edited by
      #2

      The above issue doesn't seem to be the problem. I moved the entire method to the mainwindow class so that no objects used are created inside main().

      Another possibility that has occurred to me is that the TcpSocket actually used to send the data is located in a separate dll. Will this have a separate heap space? I will try and see if I can make copies of the objects sent across the "boundary" to avoid this possibility works. Meanwhile... if anyone has any suggestions it would be greatly appreciated.

      1 Reply Last reply
      0
      • P Offline
        P Offline
        primem0ver
        wrote on last edited by
        #3

        Doing the above didn't help at all. I am really frustrated at this point. I cannot figure this out. In every other way than the things I have explained above, this part of my code matches the examples in the fortune cookie server/client pair. Could this be some sort of bug?

        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