I've analysed the problem using Valgrind, and it seems as though this is a bug in the
XML_Loading_Archive class. The only reason you saw it when enabling the Emacs mode was that the native plugin caused memory layout to be slightly different. Different enough that it triggered a crash instead of just random data.
That explains why you changing seemingly unrelated things changed the behaviour of the crash.
Here's the Valgrind error you get by simply loading your workspace in a plain APL session (i.e. no Emacs mode):
)load /home/emartenson/Downloads/Devices.xml
==24490== Conditional jump or move depends on uninitialised value(s)
==24490== at 0x47C452: XML_Loading_Archive::next_tag(char const*) (Archive.cc:1013)
==24490== by 0x47BD6D: XML_Loading_Archive::reset() (Archive.cc:872)
==24490== by 0x47BADA: XML_Loading_Archive::XML_Loading_Archive(char const*, int&) (Archive.cc:839)
==24490== by 0x560394: Workspace::load_WS(std::ostream&, std::vector<UCS_string, std::allocator<UCS_string> > const&) (Workspace.cc:793)
==24490== by 0x49B2CD: Command::process_line(UCS_string&) (Command.def:37)
==24490== by 0x49AE63: Command::process_line() (Command.cc:63)
==24490== by 0x55CA6B: Workspace::immediate_execution(bool) (Workspace.cc:129)
==24490== by 0x4BCBCC: main (main.cc:466)
==24490==
I took a look at the code, and I'm not entirely sure what's going on. The only conditional jumps that happen in the next_tag() method depends on current_char, which I presume could be uninitialised. I suppose Jürgen will have to take a look at this and determine how to fix this one.
Regards,
Elias