XMLTools crashes Notepad++ about xmltools HOT 10 OPEN

I noticed that your sample file is a HTML file, not a XML file, and content is not well structuted. For instance, tag img on line 46 is never closed. Therefore xml is not valid and xpath cannot be evaluated.

Now I agree that the error should be catched and displayed instead of making NPP terminate. I'll work on this asap.

from xmltools.

Trying to evaluate an XPath expression, or validate a huge XML file can cause Notepad++ to crash outright. An error should be displayed instead of causing Notepad++ to terminate.

Running N++ v7.6.4, XMLTools v2.4.11.0, both 64 bit.

I agree with you, Logan [@effleurager] - the problem ought to be trapped and handled gracefully.

from xmltools.

I started debugging and the crash happens on this instruction in the "XMLValidation" function:

doc = pXmlReadMemory (data, currentLength, "noname.xml", NULL, getFlags ());

I tried to compile and use the latest version of libxml2 (2.9.10) available here and now that instruction is not crashing the plugin anymore! 🎉
Unfortunately the maintainer of the libxml2 windows port (Igor Zlatovic) has not updated it's windows binaries repository since 2015.

from xmltools.

No idea what "huge" is exactly, but I had crashes in the past with this function on XMLs that are only like 1 MB in size. After the crash my whole N++ was damaged and I lost all unopened files. But hey, better than some other crash I had with N++ that 0x00 filled every opened file some day (I had backups for both occasions).

I now tried some Path Evaluations and they worked, but once I closed N++, it crashed. Compiled my own libxml2-2.dll and no longer crashes. Time will tell.

EDIT:
How to compile with Visual Studio:

• Get code from https://gitlab.gnome.org/GNOME/libxml2
• Run /win32/configure.js
• Open solution file, set to release dll, x86 - you still have to change "Configuration Type" to .dll in the properties.
• Might have to add "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x86\WS2_32.Lib" to the linker if you get linker errors in nanoftp.obj
• Since libiconv is not there for whatever reason you have to change xmlversion.h to not use it (#define LIBXML_ICONV_ENABLED -> IF 0).

from xmltools.

The file linked is 2167 KB, but huge is whatever arbitrary size/depth limit gets hit which causes the crash.

Is there a particular reason you're compiling for x86 instead of x64?

from xmltools.

Is there a particular reason you're compiling for x86 instead of x64?

I run 32bit N++, since I think not all my Plugins are 64bit.
I can compile a 64bit dll for you if you want to test it with an updated dll and cannot compile it yourself.

from xmltools.

@ganego I'll only be able to compile it when I get back to my laptop in a few days, but that's not really the issue here. I prefer XSLT processors for my use case.

I can create a PR updating the library when I get back, if no one else does before me.

from xmltools.

Is there a particular reason you're compiling for x86 instead of x64?

I can compile a 64bit dll for you if you want to test it with an updated dll and cannot compile it yourself.

@ganego I've searched through the files, and not found any reference to a toggle for 32/64-bit compilation. This all, presuming I even know what to look for – can you point out what I need to change? I'm only getting it sucessfully compiled for 32-bit.

from xmltools.

Just create a new configuration for x64.

Build -> Configuration Manager -> Release DLL | Platform (New->x64 & copy Settings).
Then change the Windows Kit library to the x64 bit one ("C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x64\WS2_32.Lib") in the Linker.

Compiles fine here. Though I did not test the dll.

from xmltools.

Testing the dll shows it appears to work, but that's not going to be enough to post as a trustworthy recompilation if the binary port maintainer isn't keeping their site up-to-date. I've emailed Igor Zlatkovic, but until then it's a decent interim measure.

from xmltools.