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:
> 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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
