On 14 Gen, 21:24, "[email protected]" <[email protected]> wrote:
> Wow, maybe I am an expert after all... :P
>
> Index: source/common/launch.h
> ===================================================================
> --- source/common/launch.h (revision 594)
> +++ source/common/launch.h (working copy)
> @@ -79,16 +79,17 @@
> */
> /*typedef _typeobject;*/
> typedef struct _object {
> - int ob_refcnt;
> + /*int ob_refcnt; */
> + ssize_t ob_refcnt;
> struct _typeobject *ob_type;
> } PyObject;
> typedef void (*destructor)(PyObject *);
> typedef struct _typeobject {
> - int ob_refcnt;
> + ssize_t ob_refcnt;
> struct _typeobject *ob_type;
> - int ob_size;
> + ssize_t ob_size;
> char *tp_name; /* For printing */
> - int tp_basicsize, tp_itemsize; /* For allocation */
> + ssize_t tp_basicsize, tp_itemsize; /* For allocation */
> destructor tp_dealloc;
> /* ignore the rest.... */
> } PyTypeObject;
>
> On Jan 14, 2:38 pm, "[email protected]" <[email protected]>
> wrote:
Still some issue here
#################### FINISHING TEST test_getfilesystemencoding
####################
{'failed': ['test_site_module', 'test_error_during_import'],
'passed': ['test1',
'test2',
'test5',
'test6',
'test7',
'test8',
'test9',
'test10',
'test11',
'test12',
'test13',
'test14',
'test_f_option',
'test-zipimport1',
'test-zipimport2',
'test-nestedlaunch0',
'test-nestedlaunch1',
'test-relative-import',
'test_getfilesystemencoding']}
anyway this is by far better than results reported in the original
post by
Anthony.
> > I'm really not an expert on x86_64 architecture, but I think this
> > might have something to do with the differences between PyInstaller's
> > PyObject and Python's own PyObject.
>
> > In PyInstaller, ob_refcnt is of type int
> > In Python, ob_refcnt is of type Py_ssize_t
>
> > If the "mods" variable is "uninitialized" from
> > PI_PyString_FromStringAndSize, perhaps Py_DECREF is somehow finding
> > out that ob_refcnt is pointing nowhere... Or, perhaps things before
> > ob_refcnt isn't padded out to the length of py_ssize_t, and therefore
> > Py_DECREF is looking past the boundaries of the empty string....
>
> > I don't have more that 4Gb or RAM in the x86_64 machine, but perhaps
> > the kernel does have support for that compiled in. Perhaps that's why
> > this issue shows up on some 64 bit systems but not others.
>
> > Just a thought. Any more requests on what to debug?
>
> > PEP reference about Py_ssize_t:http://www.python.org/dev/peps/pep-0353/
>
> > On Jan 11, 7:44 am, Giovanni Bajo <[email protected]> wrote:
>
> > > On sab, 2009-01-10 at 04:04 -0800, Antonio Valentino wrote:
>
> > > > On 10 Gen, 03:51, Giovanni Bajo <[email protected]> wrote:
> > > > > On ven, 2009-01-09 at 12:18 -0800, Antonio Valentino wrote:
>
> > > > > > On 9 Gen, 20:58, Giovanni Bajo <[email protected]> wrote:
> > > > > > > On 1/9/2009 4:44 PM, [email protected] wrote:
>
> > > > > > > > I can reproduce this problem on my mandriva x86_64 setup. I
> > > > > > > > tried a
> > > > > > > > few random revisions of SVN trunk yesterday, all with the same
> > > > > > > > problem. The code segfaults at source/common/launch.c:665 for
> > > > > > > > me:
>
> > > > > > > > 664
> > > > > > > > 665 Py_DECREF(mods);
> > > > > > > > 666 free(modbuf);
>
> > > > > > > The DECREF is surely not wrong, so removing it is just papering
> > > > > > > over the
> > > > > > > real problem, as far as I can tell.
>
> > > > > > > Is mods a valid pointer or is it NULL, when it crashes? If it's
> > > > > > > NULL,
> > > > > > > what's the value of the expression "ntohl(ptoc->ulen) - 8"?
>
> > > > > > (gdb) print mods
> > > > > > $1 = (PyObject *) 0x23a1460
> > > > > > (gdb) print ntohl(ptoc->ulen)
> > > > > > $2 = 19728
>
> > > > > print *mods ?
>
> > > > (gdb) print *mods
> > > > $1 = {ob_refcnt = 0, ob_type = 0x7f8042147ea0}
>
> > > So, the object pointed by "mods" has refcount 0 *before* calling
> > > Py_DECREF? At what point does it become zero?
> > > --
> > > Giovanni Bajo
> > > Develer S.r.l.http://www.develer.com
--
Antonio Valentino
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/PyInstaller?hl=en
-~----------~----~----~----~------~----~------~--~---
