Minor Bug: Segmentation fault (core dumped)

Similar to Minor bug: Seamly fails when closing last open pattern

Another conveniently timed issue, when I make a new pattern, do anything in it, close the window from the menu, (whether saving or not,) & then try making a new pattern, I get a segmentation fault, & the window closes, (& if it’s the only window, seamly2d quits as well.)

DEBUG data:

shorty@Shelob:~/Downloads$ ./Seamly2D.AppImage
Checked locale: "en_US"
DEBUG:Log file /home/shorty/.config/Seamly2DTeam/seamly2d-pid3668.log was locked.
DEBUG:Clearing old logs
DEBUG:Version: "0.6.0.1"
DEBUG:Build revision: Git:c403baf205f0
DEBUG:"Based on Qt 5.13.2 (GCC 7.5.0, 64 bit)"
DEBUG:Built on Jul 30 2020 at 19:27:10
DEBUG:Command-line arguments: ("./Seamly2D.AppImage")
DEBUG:Process ID: 3668
DEBUG:Checked locale: "en_US"
DEBUG:Initialization property browser.
DEBUG:Initialization groups dock.
DEBUG:Can't get tag Groups.
DEBUG:Updating recent file actions.
DEBUG:Reading settings.
DEBUG:Set current name to ""
DEBUG:New PP.
DEBUG:Generated PP name: Pattern piece 1
DEBUG:First PP
DEBUG:PP name: Pattern piece 1
DEBUG:Redo.
DEBUG:Parsing pattern.
DEBUG:Lite parse.
DEBUG:Tag version.
DEBUG:Tag unit.
DEBUG:Tag description.
DEBUG:Tag notes.
DEBUG:Tag measurements.
DEBUG:Tag increments.
DEBUG:Tag draw.
DEBUG:Tag calculation.
DEBUG:Tag point.
DEBUG:Tag modeling.
DEBUG:Tag details.
DEBUG:Current pattern piece Pattern piece 1
DEBUG:Scene size updated.
DEBUG:Canceling tool.
DEBUG:Dialog closed.
DEBUG:Point label: A1
DEBUG:Redo.
DEBUG:Arrow tool.
DEBUG:Canceling tool.
DEBUG:Dialog closed.
DEBUG:Enabled arrow tool.
DEBUG:Parsing pattern.
DEBUG:Lite parse.
DEBUG:Tag version.
DEBUG:Tag unit.
DEBUG:Tag description.
DEBUG:Tag notes.
DEBUG:Tag measurements.
DEBUG:Tag increments.
DEBUG:Tag draw.
DEBUG:Tag calculation.
DEBUG:Tag point.
DEBUG:Tag point.
DEBUG:Tag modeling.
DEBUG:Tag details.
DEBUG:Current pattern piece Pattern piece 1
DEBUG:Scene size updated.
DEBUG:Show draw scene
DEBUG:Arrow tool.
DEBUG:Canceling tool.
DEBUG:Dialog closed.
DEBUG:Enabled arrow tool.
DEBUG:File  closed correct.
DEBUG:Reseting main window.
DEBUG:Unlocked pattern file.
DEBUG:Show draw scene
DEBUG:Arrow tool.
DEBUG:Canceling tool.
DEBUG:Dialog closed.
DEBUG:Enabled arrow tool.
DEBUG:Returned to Draw mode.
DEBUG:Clearing container data.
DEBUG:Clearing pattern.
DEBUG:Set current name to ""
DEBUG:Clearing scenes.
DEBUG:Arrow tool.
DEBUG:Canceling tool.
DEBUG:Dialog closed.
DEBUG:Enabled arrow tool.
DEBUG:New PP.
DEBUG:Generated PP name: Pattern piece 1
DEBUG:First PP
DEBUG:PP name: Pattern piece 1
Segmentation fault (core dumped)
shorty@Shelob:~/Downloads$

Same thing happens in the regular install as well. I don’t think it’s a big deal, but I found it while stress-testing Seamly while I had no internet for a week, & don’t know if it might be more important than I realize. It didn’t interfere with any active work.

1 Like

I can’t replicate on Windows, Same build date July 30 2020. Opened Seamly, opened a test file. Changed something. Clicked File/Exit. it asked me to save, I saved, app closed. Reopened Seamly, clicked New, got prompt for new pattern piece 1. Clicked OK. Runs fine.

Did the same again, but I didn’t save, app closed. Reopened Seamly, clicked New, got prompt for new pattern piece 1. Clicked Ok. Runs fine.

Going to check the Ubuntu version, July 30 2020.

1 Like

I apparently deleted that version when cleaning out the unneeded test builds. We have test builds every week. I’m testing with aug 17 2020.

1 Like

Could not replicate with Seamly2d.appimage of 17 Aug 2020. Hmmm.

1 Like

What about with Window/Close pattern?

The intent is to keep working in Seamly on a new pattern, without having unused windows left lying around, not to quit the application. Though I guess the difference, at least on Linux, is just smoke&mirrors.

1 Like

Can you restate the steps? I have misunderstood you. Can you list each step separately, one step per line?

2 Likes

The only way I know to close Seamly is from the top menu choose File/Exit or click on the upper right ‘x’. Is there another way? Can you share a screenshot?

1 Like
  • In Seamly window 1, open & update a pattern.
  • In Seamlhy window 1, click the New icon which creates Seamly window 2
  • In Seamly window 2, click the New icon again to create a new pattern piece 1.
  • Then close Seamly window 1 with a) File/exit, b) upper right ‘x’, c) some other way
1 Like

@Douglas did mention in the other error thread that he was doing away with it. Maybe the dev copy doesn’t have it any more? Here’s the shot: WindowMenu

Okay, I hope I noticed all the details this time :grin:

  • In a new GREY blank waiting-for-a-new-pattern-to-be-made startup screen Seamly window, select “new” pattern
  • do some work
  • using, (possibly deprecated) “close pattern” option in the (being deprecated) window menu (see picture above), close the pattern. Possibly I decided I was going in completely the wrong direction, & it would be easier to just start with a blank canvas.
  • I didn’t bother saving the pattern this time, I did try saving once before & it didn’t make a difference.
  • now I’m at the WHITE blank waiting-for-a-new-pattern-to-be-made startup screen
  • I once more click “New”
  • it asks what to name the new pattern piece
  • I click “okay”
  • & the program is gone.

I’ve tried the toolbar, the file menu, & ctrl-n for the new file. All to the same effect. Also inches & cm.

:unicorn:

1 Like

Ok here’s what I did

Case 1:

  • Open Seamly window 1:
  • open pattern
  • make a change
  • Click New --> opens Seamly window 2
  • In seamly window 1 click Window/close --> Error bad id msg
  • Click OK --> Seamly window 1 closes
  • In seamly window 2
  • open pattern
  • make a change
  • Save

Case 2:

  • Open Seamly window 1:
  • open pattern
  • make a change
  • click Window/close pattern --> generates Error bad id error msg,
  • click OK --> Seamly window 1 closes
  • Open Seamly window 2:
  • open pattern
  • make a change
  • click Window/close pattern --> Error bad id msg
  • click OK --> Seamly window 2 closes

Case 3:

  • Open Seamly window 1:
  • open pattern
  • make a change
  • Open Seamly window 2:
  • click New --> opens new pattern piece dialog.
  • click OK
  • make a change
  • In seamly window 1 click Window/close pattern --> Error bad id msg
  • click OK --> Seamly window 1 closes
  • In seamly window 2 make a change
  • click save

What am I doing wrong? I don’t get a segmentation fault error. What’s your OS? What’s your Seamly version?

2 Likes

Step 2- new pattern, not open pattern. I just get the bad id error when I mess with an existing pattern, but there’s a different thread for that one.

DEBUG:Version: "0.6.0.1"
DEBUG:Build revision: Git:c403baf205f0
DEBUG:"Based on Qt 5.13.2 (GCC 7.5.0, 64 bit)"
DEBUG:Built on Jul 30 2020 at 19:27:10
DEBUG:Command-line arguments: ("./Seamly2D.AppImage")
DEBUG:Process ID: 3668
DEBUG:Checked locale: "en_US"

Ubuntu 18.04.5 LTS

1 Like

The history is not properly cleaned up upon window->close pattern. Thus even though the pattern was closed, the history entries for this pattern are still alive. If we now create a new pattern with the same name as before, things get messed up, and we end up with a segfault. If you choose a different name for the new pattern, everything is okay.

The reason is the compare-by-name in the if-clause in QRectF VPattern::ActiveDrawBoundingRect(), which returns true also for the old history items if both pattern names are the same. The segfault is raised in qobject_cast within template <typename T> QRectF VPattern::ToolBoundingRect. This is actually a segfault within the Qt library.

2 Likes

Wow. Thanks for that insight!

I just tried it with Pattern Piece 1 at the grey screen, then a whole string of Pattern Piece, before going back to Pattern Piece 1 & segfaulting.

& then I tried it the other way around.

So it’s whichever name was chosen at the grey startup screen is nitroglycerine.

1 Like

A few notes…

  1. I made a commit fix to the Window-> Close Pattern in a pending New Notch Option pull request. I say pending because it’s hung up on a test at the moment that I need to familiarize myself with.

  2. I want to make some future updates to the menus and the “Close Pattern” menu item would be moved to the File Menu… the function of it remains the same. Stay tuned. :slight_smile:

Fixed in a pending pull request.

Too much info for most users here. :wink: Can’t do anything about the segfault in the lib - sounds like an issue for Qt. For the purposes of Seamly2D it’s a simple swap of 2 lines in MainWindow->Clear().

Susan… When I click on the Bad Id message - can’t open a second pattern. - as the program closes. Anyhow, It’s all a moot point when the fix in my current New Notch Options PR is able to merge. Which BTW threw me another wrench as I now have to decipher a test on a old (problem?) test pattern piece… or we could just delete that test and the PR test passes. :slight_smile:

2 Likes

Thank you very much, @Douglas, you’re a star! I’m itching to try this build and you’re keeping me in suspense :rofl: :rofl: :rofl:

:star_struck: :star_struck: :star_struck:

1 Like

Well… you always could clone & build the issue-#282 branch. :slight_smile:

2 Likes

Hey @Douglas

:+1: Nice to see that you fixed it already :slightly_smiling_face:

However, bear in mind that swapping of Qlist items was only introduced in Qt 5.13. To be consistent, one should change the minimum required Qt version to 5.13.

But you are right, this is perhaps not the ideal place to discuss programming related issues. I would like to help and contribute some code, what is the best way to start? I have quite a lot of questions, e.g. regarding code style etc.

3 Likes

Not sure I follow… swapping of QList items has nothing to with the segfault the OP reported?

1 Like

Oops, you are totally right, my mistake :flushed:

I was caught by the keyword swapping, but you swapped lines in order to fix the bug, not items.

(My point was: There has been another merged pull request last month by another dev, which raised the Qt dependency from < 5.9 to 5.13 by swapping of items. But this is a.) not the point of this thread and was b.) implemented by someone else, correct.)

2 Likes

Sort of… the min Qt dependency is the result of choosing to use 5.13.2 on github for the builds, not neccesarily the change Roman made to eliminate that one particular deprecation. Roman used the swapItems() because he could in the automated builds on Github. No doubt he probably saw the deprecated warning while compiling.

It’s a what came first - the chicken or the egg?

I’ll just be happy when the min ver is 5.15… then I won’t see the 250+ deprecation warnings.

1 Like