Important: Please read the Qt Code of Conduct -

Mysterious SegFault only if not run after QMake

  • I'm using quite a few pointers. I will take a look to see. At first glance, everything is initialized at some point or another; the only thing that gets deleted in the code is stuff in a QList that can be dynamically added and removed (and have been in the project forever and i use deleteLater()). Not to mention that that QList starts empty and I can get my segfault by just running and then closing. What are the different ways besides 'delete' that could cause issues with a pointer being deleted twice?

  • Just the use of a pointer not initialized is always very unhealthy.

    Because the problem comes up when destructing the application/objects triggered my guess that it is delete related. Rethinking it is probably not a pointer deleted twice. it is more likely that you delete a pointer which does not point to memory.

    However, you are able to reproduce in the debugger. Check out, if it crashes always in the same area of your code. Try to narrow down to actual location where the segfault is triggered.

  • The debugger is useless to me. Since it happens after the main returns and is presumable during destructors, the stack is a bunch of question marks and it points a command in the disassembler. I can't read the code effectively there. If you want I can copy some here.

  • Here is the code involving the deleting:
    sounds is a QList containing SoundInstances(which is my own class). This is part of a 'new' function that empties the list.
    @for(int i=0;i<sounds->count();i++)

    The function that gets rid of something from sound one at a time does it in the exact same manner.


    There are no other references to the sound except a pointer to the last one that was selected (which is set to 0).

    Every other pointer i have is initialized and never deleted;

  • Comment out
    // sounds->clear();

    clear() is releasing the memory of the QList. The QList contained the pointers. Presumably something is done prior to the deleteLater() will be done and you got your crash.

  • I don't think that's the issue. The SoundInstance is actually an extension of a PushButton so it can be displayed, so if you just call sounds->clear(), the object still exists and still appears in the window. However, if you just call the loops of deleteLater(), then the QList still contains the pointer. Both appear to be necessary.

    I hope i don't sound too flustered, this is just driving me crazy.

  • Did you actually try to comment out the clear?

    Your objects are being deleted by deleteLater. If I am not completely mistaken, you are pulling the carpet you are standing on with your clear.

    btw I completely understand this driving you crazy. Would drive me crazy as well. :-(

  • So I commented everything out of my constructor so i get a blank window. When i close it, it still segfaults. No other code is running (I have breakpoints everywhere and nothing gets hit) and still I get a segfault on close.

  • This is certainly one way to taggle the problem. However, I hope you are not blindly commenting out in the constructor and forget the counterpart in the destructor. This most likely will generate additional segfaults as well.

    Your strategy is absolutely correct, but do it in a calm manner. Think about it and the consequences in your code and especially that some leftovers do not create more problems. Panicking will not help at all. Sometimes it even helps to take a break and start freshly. Actually most of the time it does for me.

  • Ok, I know it's been a little while, but my problem persists in a weird way. My desructor for my main window is as follows:

    if(workspace) delete workspace;
    if(currentlySelected) delete currentlySelected;
    if(shortcutPlay) delete shortcutPlay;
    if(shortcutVolumeUp) delete shortcutVolumeUp;
    if(shortcutVolumeDown) delete shortcutVolumeDown;
    //layer 2 first
    if(audemeLibraryAccess) delete audemeLibraryAccess;
    if(addAudeme) delete addAudeme;
    if(removeAudeme) delete removeAudeme;
    if(testPlay) delete testPlay;
    if(searchBox) delete searchBox;
    if(rewind) delete rewind;
    if(play) delete play;
    if(pause) delete pause;
    if(forward) delete forward;
    if(volume) delete volume;
    if(interactionHelp) delete interactionHelp;
    if(interactionProperties) delete interactionProperties;
    if(interactionFile) delete interactionFile;
    if(interactionFileNew) delete interactionFileNew;
    if(interactionFileOpen) delete interactionFileOpen;
    if(interactionFileSaveAs) delete interactionFileSaveAs;
    if(interactionFileSave) delete interactionFileSave;
    if(interactionFileExit) delete interactionFileExit;
    if(interactionFileChangeLibraryLocation) delete interactionFileChangeLibraryLocation;
    if(interactionFileRefreshLibrary) delete interactionFileRefreshLibrary;
    if(interactionPropertiesName) delete interactionPropertiesName;
    if(interactionPropertiesNameField) delete interactionPropertiesNameField;
    if(interactionPropertiesRelPath) delete interactionPropertiesRelPath;
    if(interactionPropertiesRelPathField) delete interactionPropertiesRelPathField;
    if(interactionPropertiesSampleRate) delete interactionPropertiesSampleRate;
    if(interactionPropertiesSampleRateField) delete interactionPropertiesSampleRateField;
    if(interactionPropertiesSamples) delete interactionPropertiesSamples;
    if(interactionPropertiesSamplesField) delete interactionPropertiesSamplesField;
    if(interactionPropertiesLength) delete interactionPropertiesLength;
    if(interactionPropertiesLengthField) delete interactionPropertiesLengthField;
    if(interactionPropertiesStartTime) delete interactionPropertiesStartTime;
    if(interactionPropertiesStartTimeField) delete interactionPropertiesStartTimeField;
    //then layer 1
    if(audemeLibrary) delete audemeLibrary;
    if(controlPanel) delete controlPanel;
    if(interactionPane) delete interactionPane;
    delete [] channelButtons;
    if(channels) delete [] channels;
    if(timer) delete timer;
    if(timerCount) delete timerCount;
    if(timerMax) delete timerMax;
    if(timerCountImage) delete timerCountImage;
    Every single pointer is being checked and, if it exists, is deleted. The weird thing is that it still segfaults at the end, but it also stops on the one line where I've expanded (delete [] channelButtons;). It stops there and does nothing when debugging like it is about to throw a segfault, but does not. It will then reach the breakpoint on the last line before segfaulting. Any thoughts as to why this might be happening as it is?

  • Moderators

    [quote author="mccurrab" date="1332519524"]So I commented everything out of my constructor so i get a blank window. When i close it, it still segfaults. No other code is running (I have breakpoints everywhere and nothing gets hit) and still I get a segfault on close.[/quote]

    Am I correct in assuming that you've commented out the items, but still have the destructor as written above? If so, are the different object pointers (workspace, currentlySelected, et al.) being initialized to 0? If not, then they'll have random values, and as such, the if statements in the destructors will still evaluate as true and the deletes will be called.

    (I see now that Koahnig asked the same question two posts up, but I don't think you addressed it in your reply.)

  • Everything is at least being initialized to 0, though most are being initialized to an object. My previous segfault came from channelButtons being deleted after channels. channels is an array of QLabels that are the parent of the corresponding QImageButton (a simple class extending QPushButton of my own creation) in channelButtons. This was an obvious mistake that I should have caught and is now fixed by switching the order being deleted, but as I said, upon exiting the program, it stops on the delete [] channelButtons line, but does not segfault like it used to

    Then of course it goes past my destructor (which seems unlikely since every other destructor should have already been called since the main window is the highest in the parent hierarchy) to segfault on something i don't know.

  • Moderators

    May be kind of late in the game to ask, but a couple of thoughts cross my mind...

    • Could/should you be taking better advantage of Qt's widget parenting system to let your destructor handle deleting all of the child objects itself, rather than you having to delete them manually? By creating them with "new whateverWidget(this)" Your MainWindow will clean them and their children up for you.

    • Why have a C-style array of QLabel pointers? Why not use a QList<QLabel *>?

  • I used to not have any destructors and just let it do everything by default. Unfortunately, it led to having a segfault that I could do nothing about. So i made the destructors myself.

    I was thinking about switching to using QList, but I started with an array because i am more used to arrays than QLists. At this point I think I am going to convert them, but I'm not sure if it will fix this issue.

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

  • [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": , 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!

Log in to reply