crash on startup. Windows XP, Inkscape rev 12549

[Alvin Penner]

on startup I get a crash with the following message:

C:\InkscapeBZR\inkscape>inkscape
terminate called after throwing an instance of 'FactoryExceptions::TypeNotRegistered'
  what(): svg:svg

Emergency save activated!

[jazzynico (jazzynico)]

Confirmed. Same OS, same Inkcape revision.

[Markus Engel (engelmarkus)]

I assume you are using CMake to build Inkscape? Try this patch, this fixes the problem for CMake-builds.

[Alvin Penner (apenner)]

on Windows, Inkscape is normally compiled using btool. I do not see any way of applying this patch.

[Johan Engelen (johanengelen)]

Some info that might help.
When adding debug messaging to the registering method in factory.h:
         bool registerObject(std::string const &id, CreateFunction *creator) {
                 g_message("register %s", id.c_str());
                 return this->_object_map.insert(std::make_pair(id, creator)).second;
         }

We get:

D:\inkscape\trunk\inkscape>inkscape
** Message: register /tools/paintbucket
** Message: register /tools/freehand/pen
** Message: register /tools/lpetool
** Message: register /tools/select
** Message: register star
** Message: register svg:ellipse
** Message: register svg:circle
** Message: register arc
** Message: register spiral
** Message: register svg:polygon
** Message: register /tools/dropper
** Message: register inkscape:path-effect
** Message: register svg:filter
** Message: register svg:meshGradient
** Message: register inkscape:box3dside
** Message: register svg:marker
** Message: register /tools/gradient
** Message: register /tools/connector
** Message: register inkscape:offset
** Message: register svg:tspan
** Message: register svg:textPath
** Message: register /tools/text
** Message: register svg:use
** Message: register svg:image
** Message: register svg:stop
** Message: register svg:path
** Message: register inkscape:box3d
** Message: register svg:tref
** Message: register svg:flowRoot
** Message: register svg:text
** Message: register svg:color-profile
** Message: register inkscape:persp3d
** Message: register svg:g
** Message: register svg:pattern
** Message: register svg:mask
** Message: register svg:clipPath
** Message: register svg:switch
** Message: register svg:rect
** Message: register sodipodi:namedview
** Message: register sodipodi:guide
** Message: register inkscape:grid
RegistryTool: Could not set the value 'D:\inkscape\trunk\inkscape\inkscape.exe'
terminate called after throwing an instance of 'FactoryExceptions::TypeNotRegist
ered'
  what(): svg:svg

So many objects get registered, but not svg:svg before it is requested. It is weird that it is requested at all, because that only happens in some deep function, not in simply stuff that should be initialized on booting inkscape (to initialize static vars). In any case, it happens. Where? SPDocument::createDoc is where the crashing request is made (checked it with debugging means). Now the question is, how does code execution end up that far down the line, before even initializing all static variables? Compiler optimizations?

[Johan Engelen (johanengelen)]

Same list of registered objects but then for iOS (thanks ~suv):
  https://gist.github.com/su-v/995a5a8d3dba3057dc96

[Markus Engel (engelmarkus)]

I'm quite sure that the problem is the same as with cmake and autotools: In build.xml a static library is built out of all the inkscape files:
> <target name="lib" depends="compile"
> description="create a static library">
> <staticlib command="${archutil}ar crsv"
> file="${build}/libinkscape.a">

And the linker doesn't even include the code to register "svg:svg". Search the binary for it, you probably won't find its registration.
So the solution to this problem is to adjust build.xml to directly link together all the files and not building the static library at all.

[Johan Engelen (johanengelen)]

Still get the crash on windows with -O0 -g.

[Markus Engel (engelmarkus)]

I attached a patch that describes what I want to do. I don't know the right syntax however. Can you give that a try?

[Johan Engelen (johanengelen)]

I have traced it back to the following functions (think of it as a stack trace):
  main!
  sp_main_gui if (create_new)
  sp_file_new_default
  sp_file_new
  SPDocument::createNewDoc
  SPDocument::createDoc --> calls SPFactory::instance().createObject(typeString) and crash because svg:svg is not in the list yet.

So now to find out why main is called, and why a whole lot of static variables are not initialized before that.

[Johan Engelen (johanengelen)]

Perhaps the answer is here?
http://stackoverflow.com/questions/9459980/c-global-variable-not-initialized-when-linked-through-static-libraries-but-ok

[Markus Engel (engelmarkus)]

Yes that's the answer. This happened with the other build systems as well until we disabled libinkscape.a.
You could use --whole-archive as a linker flag, but that's not ideal either. So I think directly linking every object file together is simpler.

[Johan Engelen (johanengelen)]

Was already trying --whole-archive, but it hangs the linker somehow.
I'll see if i can work out how to do it with build.xml.

[Johan Engelen (johanengelen)]

this patch fixes the windows build by no longer linking an intermediate lib.

not sure if we really want this global variable registration thing, because of its flakiness (as we have proven in the past days), but at least we can work again

[Markus Engel (engelmarkus)]

Once this has settled, no one will ask for the lib anymore.
I mean, modularization is always cool, isn't it? With this factory, one could even register their own node type out of an extension or so.
Btw, sorry for the inconvenience. A few hours ago I hadn't even realized there are three build systems.

[Krzysztof Kosinski (tweenk)]

Global registration would also work if libinkscape was a shared library rather than a static library, but doing this with Autotools is a little painful.

[Alvin Penner (apenner)]

patch seems to work, thanks for staying up late!

it probably doesn't matter, but line 46 should probably be changed from
+ <!--include name="../inkres.o"/>
to
+ <!--include name="../inkres.o"/-->

(my xml editor complained)

[Johan Engelen (johanengelen)]

Response to "I mean, modularization is always cool, isn't it? With this factory, one could even register their own node type out of an extension or so."
Indeed, it is nice. What I don't like is the implicit calling of all the global var init code pieces. I'd rather have a function somewhere that registers all nodes at once, at a well-defined time during start up. That would not block extensions from registering their own nodetypes.

[Markus Engel (engelmarkus)]

Building on Windows was fixed in r12559.

[David Mathog (mathog)]

The fix to this problem just ran us straight into the command line length limit. See bug #1251405.