works fine for me, with pyside from mainline and python-debug from ubuntu
repository.

Which version of pyside are you using?

It's working here with a fresh PySide from git.

Could you post where did you get PySide from?

I use the current head fetched by the description at:
http://developer.qt.nokia.com/wiki/Building_PySide_on_Linux

git describe delivers:
apiextractor  0.7.0-107-gf6cfe3e
generatorrunner  0.6.0-68-gccbdbb5
shiboken  0.4.0-394-g0764d6b
pyside  0.4.0-715-g6e16fd8

Do you use a python with debugging enabled?

my  git describe output:

apiextractor: 0.10.2-5-gf6cfe3e
generatorrunner: 0.6.9-4-g84572f3
shiboken: 1.0.2-25-g0764d6b
pyside: 1.0.2-63-g6e16fd8


try update your repository they apparently is very old.

I updated it 15 Minutes ago. Maybe "git describe" is not the appropriate way to
find the "revision" number. I have no experience with git, if you tell what I
should do to identify the HEAD i will try that. But as I mentioned before the
last update was at 16:45 cet.

I did some code inspection. The error comes from the function below.
As you can see it is only defined in debug mode. In non debug mode it will
probably just ignore the error silently. But I it think this could point to
an undiscovered reference bug, which will potentially could cause some weird
(very hard to analyze) crashes.



#ifdef Py_REF_DEBUG
/* Log a fatal error; doesn't return. */
void
_Py_NegativeRefcount(const char *fname, int lineno, PyObject *op)
{
    char buf[300];

    PyOS_snprintf(buf, sizeof(buf),
                  "%s:%i object at %p has negative ref count "
                  "%" PY_FORMAT_SIZE_T "d",
                  fname, lineno, op, op->ob_refcnt);
    Py_FatalError(buf);
}

#endif /* Py_REF_DEBUG */

This is probably a bug, but is much hard to try to fix it if nobody can
reproduce it, so the bug stays on the limbo, I can't confirm neither invalidate
it at the moment.

(In reply to comment #7)
> This is probably a bug, but is much hard to try to fix it if nobody can
> reproduce it, so the bug stays on the limbo, I can't confirm neither invalidate
> it at the moment.

Were you able to reproduce this after all because you made it P2? Or just a
mistake?

Ok I did some debugging and it seems to be a compilation error.

The following happened:

The problem was to call 
   self.objectName()

with an empty object name.

The objectName wrapper calls the following method in 
file pyside_qtcore_python.h:

static PyObject* toPython(const QString& cppObj)
    {
        const int N = cppObj.length();
        wchar_t* str = new wchar_t[N];
        cppObj.toWCharArray(str);
        PyObject* pyObj = PyUnicode_FromWideChar(str, N);
        delete[] str;
        return pyObj;
    }

If the object name is empty PyUnicode_FromWideChar returns a 
non NULL (apparently not initialized) python object pointer 
with the reference counter == 0. This pointer is returned to 
the interpreter as result value. And the interpreter decrements
the wrong value. In consequence the statement 

  print self.objectName()

crashed with a segfault. 


I tried to confirm this behavior in a nondebug python version.
But there everything works fine (print self.objectName() didn't crash)

Maybe the following strange detail is informative:
The PyUnicode_FromWideChar function seemed not to be the one provided 
by python. (During debugging, when I tried to step into the function 
I entered some weird assembler code, which didn't correspond to the 
original c-code(As far as I could mentally disassemble it).

What I still don't know: Did someone tried to reproduce that behavior
with a debug enabled python?
If yes and it couldn't be confirmed it seems to be a misconfiguration on my
system and the ticket can be closed.

(In reply to comment #8)
> (In reply to comment #7)
> > This is probably a bug, but is much hard to try to fix it if nobody can
> > reproduce it, so the bug stays on the limbo, I can't confirm neither invalidate
> > it at the moment.
> 
> Were you able to reproduce this after all because you made it P2? Or just a
> mistake?

No Matti, I did it P2, but didn't confirm it yet, the prioritization change was
made just in case it gets confirmed at all =]

(In reply to comment #9)
> Ok I did some debugging and it seems to be a compilation error.
> 
> The following happened:
> 
> The problem was to call 
>    self.objectName()
> 
> with an empty object name.
> 
> The objectName wrapper calls the following method in 
> file pyside_qtcore_python.h:
> 
> static PyObject* toPython(const QString& cppObj)
>     {
>         const int N = cppObj.length();
>         wchar_t* str = new wchar_t[N];
>         cppObj.toWCharArray(str);
>         PyObject* pyObj = PyUnicode_FromWideChar(str, N);
>         delete[] str;
>         return pyObj;
>     }

A possible "new wchat_t[0];" doesn't sound right to me, did you try to add the
code bellow in the first lines of toPython method?

if (cppObj.isEmpty()) {
    Shiboken::AutoDecRef t(PyTuple_New(0));
    return  PyObject_Call((PyObject*)PyUnicode_Type, t, 0);
}

> If the object name is empty PyUnicode_FromWideChar returns a 
> non NULL (apparently not initialized) python object pointer 
> with the reference counter == 0. This pointer is returned to 
> the interpreter as result value. And the interpreter decrements
> the wrong value. In consequence the statement 
> 
>   print self.objectName()
> 
> crashed with a segfault. 
> 
> 
> I tried to confirm this behavior in a nondebug python version.
> But there everything works fine (print self.objectName() didn't crash)
> 
> Maybe the following strange detail is informative:
> The PyUnicode_FromWideChar function seemed not to be the one provided 
> by python. (During debugging, when I tried to step into the function 
> I entered some weird assembler code, which didn't correspond to the 
> original c-code(As far as I could mentally disassemble it).
> 
> What I still don't know: Did someone tried to reproduce that behavior
> with a debug enabled python?
> If yes and it couldn't be confirmed it seems to be a misconfiguration on my
> system and the ticket can be closed.

(In reply to comment #11)
> 
> A possible "new wchat_t[0];" doesn't sound right to me, 
As far as I can remember the C++ spec, the code is correct and returns a NULL
pointer.


> did you try to add the
> code bellow in the first lines of toPython method?
> 
> if (cppObj.isEmpty()) {
>     Shiboken::AutoDecRef t(PyTuple_New(0));
>     return  PyObject_Call((PyObject*)PyUnicode_Type, t, 0);
> }
> 
No I didn't, If you look at PyUnicode_FromWideChar in pythons uncodeobject.c.
The function is robust against strings of size 0, returning a correct python
object. As I mentioned, I think it is a compilation (or more correct a linking
problem).
In debug python version the correct PyUnicode_FromWideChar seems not be linked
against the pyside lib (at my system at least). Unfortunately I don't have the
time for further investigations (And the problem seems to be a complex subject
with high potential of time wasting)

Check the unicode options you used to compile your Python, another possible
cause would be that you are using Python headers from your system to compile
Python and your local Python library to link it.

So could I mark this bug as invalid?

> So could I mark this bug as invalid?

I think so.

Ok, so marking as invalid.

Regards.

release 1.0.4