[Fwd: [Bug 263898] [NEW] Windows Installer crashes due to access violation]

Hi,

has anyone seem this before or could someone please test if this is
reproducible on other machines?

Thanks,
Stefan

--------------------------------------------------------------------------
Subject: [Bug 263898] [NEW] Windows Installer crashes due to access violation
--------------------------------------------------------------------------

Public bug reported:

I tried to install lxml-2.1.1.win32-py2.5.exe on my WinXP PC and got the
attached
crash from the installer.
It happened after confirming all settings and clicking the "Next" button
on the "Ready to install" page
of the installer.

Using Visual Studio Debugger to investigate crash :

Callstack :
 	ntdll.dll!_RtlEnterCriticalSection <at> 4()  + 0xb
 	msvcr71.dll!_lock_file(void * pf=0x00000000)  Line 236	C
>	msvcr71.dll!fprintf(_iobuf * str=0x00000000, const char *
format=0x0012d278, ...)  Line 63 + 0x6	C
 	lxml-2.1.1.win32-py2.5.exe!00402ca8()
 	user32.dll!77d48734()

lxml 2.1.2 and 2.0.9 released

Hi,

lxml 2.1.2 and 2.0.9 are on PyPI. Both are bug-fix releases for the stable and
mature release series. They mainly fix a thread-related memory problem that
was introduced in the last releases of both branches. Updating is recommended.

The complete changelog follows below.

Have fun,
Stefan

2.0.9 (2008-09-05)
Bugs fixed

    * Memory problem when passing documents between threads.
    * Target parser did not honour the recover option and raised an exception
      instead of calling .close() on the target.

2.1.2 (2008-09-05)
Features added

    * lxml.etree now tries to find the absolute path name of files when
      parsing from a file-like object. This helps custom resolvers when
      resolving relative URLs, as lixbml2 can prepend them with the path of
      the source document.

Bugs fixed

    * Memory problem when passing documents between threads.
    * Target parser did not honour the recover option and raised an exception

Preventing XPath injection

_______________________________________________
lxml-dev mailing list
lxml-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/lxml-dev

Re: Preventing XPath injection

On 6 Sep 2008, at 13:18, Alex Klizhentas wrote:

> Hi All, I'm facing the following issue:
>
> xslt transformations accept xpath expressions as parameters, and if  
> you
> write something like:
>
> transform(a,param = " '  '  ' ") - xpath evaluation will fail. Is  
> there any
> common/standard way to prevent that?

No, what I've been using is:

def escapeXPathString(string):
	return u"concat('', '%s')" % string.replace(u"'", u"', \"'\", '")

The first parameter to the concat function is needed because it must  
always have at least two parameters.

--
Geoffrey Sneddon
<http://gsnedders.com/>

Re: Preventing XPath injection

_______________________________________________
lxml-dev mailing list
lxml-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/lxml-dev

Re: Preventing XPath injection

On 6 Sep 2008, at 18:52, Alex Klizhentas wrote:

> That's strange, I thought it should be quoted like: '

Nope. A string is "[^"]*" or '[^']*' — it is exactly what is between  
the quotes.

--
Geoffrey Sneddon
<http://gsnedders.com/>

Re: Preventing XPath injection

Geoffrey Sneddon wrote:
> On 6 Sep 2008, at 18:52, Alex Klizhentas wrote:
> 
>> That's strange, I thought it should be quoted like: '
> 
> Nope. A string is "[^"]*" or '[^']*' — it is exactly what is between  
> the quotes.

When I was trying to figure out CSS to XPath translation, I tried to 
figure out how string quoting worked in XPath.  Unfortunately I couldn't 
find any reference to string quoting in the specs (though of course I 
might have missed it).  This seemed like a very peculiar omission.

--

-- 
Ian Bicking : ianb <at> colorstudy.com : http://blog.ianbicking.org

Re: Preventing XPath injection

On Sun, Sep 07, 2008 at 12:16:25PM -0500, Ian Bicking wrote:
> Geoffrey Sneddon wrote:
> > On 6 Sep 2008, at 18:52, Alex Klizhentas wrote:
> > 
> >> That's strange, I thought it should be quoted like: '
> > 
> > Nope. A string is "[^"]*" or '[^']*' — it is exactly what is between  
> > the quotes.
> 
> When I was trying to figure out CSS to XPath translation, I tried to 
> figure out how string quoting worked in XPath.  Unfortunately I couldn't 
> find any reference to string quoting in the specs (though of course I 
> might have missed it).  This seemed like a very peculiar omission.

XPath 2.0 spec rectifies that:

  The value of a string literal is an atomic value whose type is
  xs:string and whose value is the string denoted by the characters
  between the delimiting apostrophes or quotation marks. If the literal
  is delimited by apostrophes, two adjacent apostrophes within the
  literal are interpreted as a single apostrophe. Similarly, if the
  literal is delimited by quotation marks, two adjacent quotation marks
  within the literal are interpreted as one quotation mark.

      -- http://www.w3.org/TR/xpath20/#id-literals

XPath 1.0 is silent on the matter.  I suppose you could always
concatenate strings, e.g. concat("Look, it's a ", '"quoted string"!')...

Marius Gedminas
--

-- 
Hoping the problem  magically goes away  by ignoring it is the "microsoft
approach to programming" and should never be allowed.
                -- Linus Torvalds

_______________________________________________
lxml-dev mailing list
lxml-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/lxml-dev

Re: Preventing XPath injection

On 7 Sep 2008, at 19:05, Marius Gedminas wrote:

> XPath 1.0 is silent on the matter.  I suppose you could always
> concatenate strings, e.g. concat("Look, it's a ", '"quoted  
> string"!')...

I just read interpreted the XML EBNF as meaning there was no escaping,  
and removed leading/trailing quote char for it to be logical. Which  
seems to be how things work.

--
Geoffrey Sneddon
<http://gsnedders.com/>

lxml.html adds a default doctype to HTML documents

In [2]: from lxml import html

In [3]: t = html.fromstring("<html><p>Hello World")

In [4]: docinfo = t.getroottree().docinfo

In [5]: docinfo.public_id
Out[5]: '-//W3C//DTD HTML 4.0 Transitional//EN'

Is it possible to prevent this from occurring? I couldn't see anything in the 
API documentation but I might have been missing something obvious. Silently 
gaining incorrect data is annoying :)

--

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead