Mysterious SegFault only if not run after QMake


  • Moderators

    Qt's parent/child mechanism isn't broken. If it was leading to a segfault, then it was more than likely caused by mishandling of a pointer somewhere along the way. Adding your own destructors won't fix that problem. Even worse, it may mask the problem, thus making it a lot harder to diagnose.



  • Well that might be true (I wasn't fond of having it write my own destructors), but the only 'mishandling' of pointers comes from the dependency of channelButtons on channels. However, there's no way to remove this dependency that I can see since I need access to those buttons from the main window. Can you think of a solution (because believe me I'm getting tired of this problem)?


  • Moderators

    Ok, so let's revisit the channels/channelButtons. Can you describe how those things relate?

    You currently have an array of channels (which are what?) and an array of channelButtons (which are what?) How do they relate to each other, specifically?

    Describe that in detail, and we can probably find out where things are getting messed up. Don't worry about talking about what you've done to create or destroy them, just what they are and how they relate to each other.



  • channels are QLabels which are sound channels. They are all identical but are used to split up where sounds will be being played. The QImageButtons are being aligned in the label since its respective label is its parent and clicking it changes which channel is 'active' or will receive sounds. This is why the buttons need to be owned by the mainwindow so that the mainwindow knows which button is clicked and which channel is active. If you want I can post the majority of my code involving these 2.


  • Moderators

    If the buttons are owned by the labels (as in the label is passed to the button's constructor as its parent), then deleting the label will delete the button (and would then give you dangling pointers in your button pointers array.) It should be sufficient to just delete the labels, which will delete the buttons for you.

    Again, also, having a QList of pointers would also be cleaner than having a C-style array. It's good form and I -can't- recommend getting into the habit of using Qt's collection classes everywhere you can, instead of using something else.



  • Well, you were right (as i figured you probably were). Turning the arrays into QLists stopped the segfaults. Definitely an annoying problem that the Qt destructors messed up on the simple arrays, but at least it's fixed. Thanks. Also, did you mean "it's good form and I can recommend"? Just wanted to be sure.

    I'll be sure to comment back here if something goes awry with the destructors again.



  • first of all, use debug tools such as :dbx or gdb to find out where the error exactly occured.
    My point of view, used the pointer in a wrong way



  • Btw, segment fault is a very simple issue and can be easily found out.just use gdb or dbx,or other debug tools,see the call stacks,then located in the exact place where the error occured



  • Okay, so...yeah. I had to make some changes to my code that propagated through a lot of it and it brought back the seg faulting. As for using debuggers, as I mentioned earlier, it is seg faulting in the destructors, so the stack I am getting is mostly unintelligible. I was thinking about starting a new thread, but since this one has already served me well, I thought I'd at least see if I could find an answer here first. There is about to be a lot of code from my main window class. Can anyone see anything initially wrong here? If not, I'll post more code.

    Thanks in advance since there's no way I can TL;DR this.



  • Sorry about this post, it was code, continue on for dropbox link.



  • This is my stack when it seg faults:

    0 wvsprintfW C:\Windows\syswow64\user32.dll 0 0x75547a24
    1 ?? 0 0xd70a7b12
    2 ?? 0 0x28fa84
    3 HydraDMH!HookMessages C:\Program Files (x86)\ATI Technologies\HydraVision\HydraDMH.dll 0 0x1000d396
    4 ?? 0 0x2302b2
    5 ?? 0 0x28f674
    6 ?? 0



  • Sorry about this post, it was code, continue on for dropbox link.



  • Sorry about this post, it was code, continue on for dropbox link.



  • Sorry about this post, it was code, continue on for dropbox link.



  • Sorry about this post, it was code, continue on for dropbox link.



  • Sorry about this post, it was code, continue on for dropbox link.



  • Sorry about this post, it was code, continue on for dropbox link.



  • let me know if you guys can find anything in there. Is there any way I can just upload the source files for people to look at? This seems very inefficient.


  • Moderators

    [quote author="mccurrab" date="1332940503"]let me know if you guys can find anything in there. Is there any way I can just upload the source files for people to look at? This seems very inefficient.[/quote]

    You are correct this is inefficient, but also not intended by the platform. Larger attachments to posts need to be placed somewhere on another server and you should place the link here.
    Some people are using "dropbox":http://www.dropbox.com , but I have seen other platforms as well.

    My suggestion would be to have a compilable setup in a zip-file. This makes it easier for others to help you.



  • Okay, got the public link to a .rar containing the project!

    http://dl.dropbox.com/u/15926661/ATL2.rar


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.