Wierd error in richtextprint.h compiliation for Bitmap Headers and footers.

[Steve Cookson]

Hi Guys,

I have a working modification in wx 2.8.11 to display Bitmap Headers and
footers in RTC that I am transferring to 3.0.1.

In 2.8.11 I have:

private:

wxRichTextBuffer* m_richTextBuffer;
// Set buffers for headers and footers (Both firstpage and
continuation pages).
wxRichTextBuffer* m_firstpageHeaderBuffer;
wxRichTextBuffer* m_firstpageFooterBuffer;
wxRichTextBuffer* m_continuationHeaderBuffer;
wxRichTextBuffer* m_continuationFooterBuffer;

Which compiles without for both error in both 2.8.11 and 3.0.1, in
2.8.11 it leads to a whole area of functionality around bitmap headers
and footers. In 3.0.1, it compiles ok and then gives me a runtime error:

*** Error in `/usr/bin/perl': malloc(): memory corruption:
0x0000000004e939f0 ***
Aborted (core dumped)

If I start gdb against the core dump I find:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/perl -w /usr/local/bin/wxperl_demo.pl'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fc1826f7bb9 in __GI_raise (sig=***@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

As the message says, there is no file called raise.c on my machine.

A quick Google shows this:

"The assert macro is calling (probably indirectly) a function called
raise. This is happening inside a library that you are linking with your
code. When that library was compiled (on some other machine) there was a
file called '../nptl/sysdeps/unix/sysv/linux/raise.c', but now when it's
running on your machine that file no longer exists. If you want to make
this error go away then you probably have to download the source code
for this library."

Any suggestions?

Thanks

Steve.

[Julian Smart]

The only thing I can think of is that these variables are not
initialised properly, or maybe double-deleted. But there could be many
possibilities in the absence of more information about what's done with
the buffers. Maybe it would be safer to have these variables as objects
instead of pointers?

Regards,

Julian

Post by Steve Cookson
Hi Guys,
I have a working modification in wx 2.8.11 to display Bitmap Headers
and footers in RTC that I am transferring to 3.0.1.
wxRichTextBuffer* m_richTextBuffer;
// Set buffers for headers and footers (Both firstpage and
continuation pages).
wxRichTextBuffer* m_firstpageHeaderBuffer;
wxRichTextBuffer* m_firstpageFooterBuffer;
wxRichTextBuffer* m_continuationHeaderBuffer;
wxRichTextBuffer* m_continuationFooterBuffer;
Which compiles without for both error in both 2.8.11 and 3.0.1, in
2.8.11 it leads to a whole area of functionality around bitmap headers
0x0000000004e939f0 ***
Aborted (core dumped)
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/perl -w /usr/local/bin/wxperl_demo.pl'.
Program terminated with signal SIGABRT, Aborted.
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
As the message says, there is no file called raise.c on my machine.
"The assert macro is calling (probably indirectly) a function called
raise. This is happening inside a library that you are linking with
your code. When that library was compiled (on some other machine)
there was a file called '../nptl/sysdeps/unix/sysv/linux/raise.c', but
now when it's running on your machine that file no longer exists. If
you want to make this error go away then you probably have to download
the source code for this library."
Any suggestions?
Thanks
Steve.

[Steve Cookson]

Hi Julian,

Thanks for responding. Sorry about the spelling mistake which is now
preserved for posterity.

in the absence of more information about what's done with the buffers.

Actually nothing is done. I stripped out everything. It's vanilla

[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/perl -w /usr/local/bin/wxperl_demo.pl'.
Program terminated with signal SIGABRT, Aborted.
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

However, I did some more research and it seems to be not unknown. It
seems to be an interaction between GTK+ (wxGTK) and X11 (XOrg) on
multiprocessor systems. There are a few fixes around. Here is a
typical one:

/* wxGTK and X11 multihtreading issues
===================================
Although they have probably always been present, I have
recently (08/2011) come across a number of X11 related multithreading
issues when running on more recent versions of GTK+ (wxGTK)
and X11 (XOrg) on multiprocessor systems. These all seem to
relate to the use of modeless top level windows such as
wxProgressDialog and multithreading OpenGL rendering, either
individually or together. These issues can all be resolved by
calling the X11 function XinitThreads before any other X
related calls have been made. The following code is conditional
on the use of wxGTK, but be aware these issues can occur
whenever the X windowing system is used. In my view the making
of such a low level windowing system call should be the responsibility
of wxWidgets (and GTK+ if that is used) but that is not happening with
current releases (08/2011). */
#if defined(__WXGTK__) && !defined(NO_XINITTHREADS)
IMPLEMENT_APP_NO_MAIN(vtApp)

int main(int argc, char *argv[])
{
// I have decided to only call XInitThreads on multi processor systems.
// However I believe that the same multithreading issues can arise on single
// processor systems due to pre-emptive multi-tasking, albeit much more
// rarely. The classic symptom of a X multithreading problem is the assert
// xcb_io.c:140: dequeue_pending_request: Assertion `req == dpy->xcb->pending_requests' failed
// or xcb_io.c .... Unknown request in queue while dequeuing
// If you see anyhting like this on a single processor system then try commenting out this test.
if (sysconf (_SC_NPROCESSORS_ONLN) > 1)
XInitThreads();
return wxEntry(argc, argv);

}
#else
IMPLEMENT_APP(vtApp)
#endif

I'm running wxPerl, and so it's not obvious to me where to insert this.
I could just insert it in the offending module (RTC) and try it.

Thanks,

Steve.