Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assertion failed: hm.v != t->h.v. #435

Closed
nazar-pc opened this issue May 30, 2019 · 15 comments
Closed

Assertion failed: hm.v != t->h.v. #435

nazar-pc opened this issue May 30, 2019 · 15 comments
Labels

Comments

@nazar-pc
Copy link

System information

SolveSpace version: 3.0.0~9ac55f3 (from ppa)

Operating system: Ubuntu 19.10

Expected behavior

Opening model shouldn't crash an app

Actual behavior

Application crashes while opening one of the bigger models I have

Additional information

This is console output during crash:

File /build/solvespace-U5Xyqq/solvespace-3.0.0~git1362-9ac55f3/src/dsc.h, line 336, function Add:
Assertion failed: hm.v != t->h.v.
Message: Handle isn't unique.
fish: “solvespace” terminated by signal SIGABRT (Abort)

I would prefer to not share the file, but it includes multiple other files liked into bigger model, some of which also linked with other files.
I was using older 3.0.0 version before and it worked, but can't say confidently when I have opened that exact file last time and what build was installed back then.

@whitequark whitequark added the bug label May 30, 2019
@whitequark
Copy link
Contributor

Does it work in commit 406c55e ?

@nazar-pc
Copy link
Author

Yes, it does, as you can see the model is quite heavy even for my beefy machine:

Generate::REGEN (for bounding box) took 7649 ms
Generate::REGEN took 15063 ms
Generate::ALL (for bounding box) took 8193 ms
Generate::ALL took 15938 ms
Generate::DIRTY (for bounding box) took 7455 ms
Generate::DIRTY took 14935 ms

@whitequark
Copy link
Contributor

So, since you can't share the file, it's going to be pretty painful, because the bug is in bd84bc1 but I have no idea where. I would need, at least, a backtrace to the assertion, plus you'll need to add a dbp statement to Remap to see if it's ever called (or if it's an error in initial loading).

@nazar-pc
Copy link
Author

Can I send a file privately to your email from GitHub account to make things easier?

@whitequark
Copy link
Contributor

My email is whitequark@whitequark.org. But I don't think you can send emails via GitHub itself.

@nazar-pc
Copy link
Author

Not through GitHub itself, I meant you have an email specified in your profile.
Anyway, I've sent you an email with project, hopefully it helps.

@tomjnixon
Copy link

tomjnixon commented Jun 23, 2019

I just had this crash too (on cb0fdb1) with a simpler-sounding model, would you like it or do you already have enough info?

Backtrace:

#0  0x00007ffff646a82f in raise () at /usr/lib/libc.so.6
#1  0x00007ffff6455672 in abort () at /usr/lib/libc.so.6
#2  0x0000555555798cd5 in SolveSpace::Platform::GetSettings() ()
#3  0x00005555558ca9d2 in SolveSpace::AssertFailure(char const*, unsigned int, char const*, char const*, char const*) ()
#4  0x000055555580f2f6 in SolveSpace::IdList<SolveSpace::Entity, SolveSpace::hEntity>::Add(SolveSpace::Entity*) ()
#5  0x000055555582f18b in SolveSpace::Group::MakeExtrusionTopBottomFaces(SolveSpace::IdList<SolveSpace::Entity, SolveSpace::hEntity>*, SolveSpace::hEntity) ()
#6  0x000055555582c771 in SolveSpace::Group::Generate(SolveSpace::IdList<SolveSpace::Entity, SolveSpace::hEntity>*, SolveSpace::IdList<SolveSpace::Param, SolveSpace::hParam>*) ()
#7  0x0000555555816d20 in SolveSpace::SolveSpaceUI::GenerateAll(SolveSpace::SolveSpaceUI::Generate, bool, bool) ()
#8  0x0000555555816a58 in SolveSpace::SolveSpaceUI::GenerateAll(SolveSpace::SolveSpaceUI::Generate, bool, bool) ()
#9  0x000055555577f37e in void std::__invoke_impl<void, void (SolveSpace::SolveSpaceUI::*&)(SolveSpace::SolveSpaceUI::Generate, bool, bool), SolveSpace::SolveSpaceUI*&, SolveSpace::SolveSpaceUI::Generate&, bool&, bool&>(std::__invoke_memfun_deref, void (SolveSpace::SolveSpaceUI::*&)(SolveSpace::SolveSpaceUI::Generate, bool, bool), SolveSpace::SolveSpaceUI*&, SolveSpace::SolveSpaceUI::Generate&, bool&, bool&) ()
#10 0x000055555577ee80 in std::__invoke_result<void (SolveSpace::SolveSpaceUI::*&)(SolveSpace::SolveSpaceUI::Generate, bool, bool), SolveSpace::SolveSpaceUI*&, SolveSpace::SolveSpaceUI::Generate&, bool&, bool&>::type std::__invoke<void (SolveSpace::SolveSpaceUI::*&)(SolveSpace::SolveSpaceUI::Generate, bool, bool), SolveSpace::SolveSpaceUI*&, SolveSpace::SolveSpaceUI::Generate&, bool&, bool&>(void (SolveSpace::SolveSpaceUI::*&)(SolveSpace::SolveSpaceUI::Generate, bool, bool), SolveSpace::SolveSpaceUI*&, SolveSpace::SolveSpaceUI::Generate&, bool&, bool&) ()
#11 0x000055555577e777 in void std::_Bind<void (SolveSpace::SolveSpaceUI::*(SolveSpace::SolveSpaceUI*, SolveSpace::SolveSpaceUI::Generate, bool, bool))(SolveSpace::SolveSpaceUI::Generate, bool, bool)>::__call<void, , 0ul, 1ul, 2ul, 3ul>(std::tuple<>&&, std::_Index_tuple<0ul, 1ul, 2ul, 3ul>) ()
#12 0x000055555577da51 in void std::_Bind<void (SolveSpace::SolveSpaceUI::*(SolveSpace::SolveSpaceUI*, SolveSpace::SolveSpaceUI::Generate, bool, bool))(SolveSpace::SolveSpaceUI::Generate, bool, bool)>::operator()<, void>() ()
#13 0x000055555577c732 in std::_Function_handler<void (), std::_Bind<void (SolveSpace::SolveSpaceUI::*(SolveSpace::SolveSpaceUI*, SolveSpace::SolveSpaceUI::Generate, bool, bool))(SolveSpace::SolveSpaceUI::Generate, bool, bool)> >::_M_invoke(std::_Any_data const&) ()
#14 0x00005555557a22b2 in std::function<void ()>::operator()() const ()
#15 0x000055555579b458 in SolveSpace::Platform::TimerImplGtk::RunAfter(unsigned int)::{lambda()#1}::operator()() const ()
#16 0x00005555557aa23e in sigc::adaptor_functor<SolveSpace::Platform::TimerImplGtk::RunAfter(unsigned int)::{lambda()#1}>::operator()() const ()
#17 0x00005555557a8427 in sigc::internal::slot_call0<SolveSpace::Platform::TimerImplGtk::RunAfter(unsigned int)::{lambda()#1}, bool>::call_it(sigc::internal::slot_rep*) ()
#18 0x00007ffff6e48f52 in  () at /usr/lib/libglibmm-2.4.so.1
#19 0x00007ffff6ccdfa3 in  () at /usr/lib/libglib-2.0.so.0
#20 0x00007ffff6cce7b1 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#21 0x00007ffff6cd0869 in  () at /usr/lib/libglib-2.0.so.0
#22 0x00007ffff6cd17f2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#23 0x00007ffff71e49bf in gtk_main () at /usr/lib/libgtk-3.so.0
#24 0x0000555555799beb in SolveSpace::Platform::RunGui() ()
#25 0x0000555555798898 in main ()

@whitequark
Copy link
Contributor

Simpler is always nicer.

@tomjnixon
Copy link

Here you go:

http://misc.tomn.co.uk/repro_435.slvs

Go to the sketch labelled "THIS ONE" and add a point to the quadrilateral.

@ghost
Copy link

ghost commented Jun 24, 2019

repro.zip
I have another example from cb0fdb1 :

  1. activate g002-sketch-in-plane
  2. select the line tool
  3. click any point in the sketch
  4. the application should crash

@tomjnixon
Copy link

I don't quite understand why yet, but adding +1 in Group::Remap like this:

        std::tie(it, inserted) =
            remap.insert({ { in, copyNumber }, { (uint32_t)remap.size() + 1 } });

solves it for files I have.

This replicates the behaviour of AddAndAssignId; I guess 0 is used as a special entity number?

@whitequark
Copy link
Contributor

You're absolutely right. I reviewed this code more than once, wrote tests for it, and still missed it somehow...

@whitequark
Copy link
Contributor

Thanks everyone, fixed in 49a7f86.

@whitequark
Copy link
Contributor

PSA: all files created in the last 25 days (between bd84bc1 and 49a7f86) are subtly corrupted, with some entities remapped to Entity::NO_ENTITY. You can check if a file is good or bad using this Python one-liner:

$ python -c 'import sys; print("BAD" if "Group.remap={\n    0" in open(sys.argv[1]).read() else "GOOD", sys.argv[1])' file.slvs

It's not entirely clear what the full consequences are. In any case, this is recoverable by removing any entires in Group.remap lists that start with 0.

@whitequark
Copy link
Contributor

I've added some code to recover the corrupted files in 02d7f0c. No action is required. If the recovery process causes data loss (which it should not), this will be indicated by the usual "Additional sketch elements were deleted" dialog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants