Minor Bug: Segmentation fault (core dumped)

Bug Reports / Issues
3

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
4

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

1 Like
5

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
6

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

2 Likes
7

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
8
  • 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
9

@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
10

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
11

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
12

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
13

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
14

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
15

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
16

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

2 Likes
17

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
18

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

1 Like
19

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
20

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
21

The current Debian LTS release comes with Qt 5.11.3 and the current Ubuntu 20.4 LTS with Qt 5.12.8. So even if people run the latest Debian-based LTS OS, they won’t be able to contribute code until 2022 (unless they install PPAs or the MaintenanceTool provided by the Qt Company).

I personally don’t mind as I code by myself with 5.15, but other people are relying on the the official repositories and won’t be able to compile the code anymore.

1 Like
22

Hi @Marco! Would you like to update our Github Actions pipeline so that Ubuntu builds with Qt 5.13.2?

1 Like