Hello,
I've recently stumbled upon a case when one of our elements exceeded 64K in
size (I deal with a lot of legacy pre-GST code, so this issue is an artifact
of that).
Approaching or exceeding 64K resulted in a number of rather peculiar
consequences (reproduced on both Linux and Windows). For example,
1. when sizeof(element) gets close to 64K, I got the following
(gst-launch-0.10:2236): GLib-GObject-WARNING **: specified instance size for
type `testelement' is smaller than the parent type's `GstElement' instance
size
(gst-launch-0.10:2236): GLib-CRITICAL **: g_once_init_leave: assertion
`initialization_value != 0' failed
** (gst-launch-0.10:2236): CRITICAL **: file
..\..\..\Source\gstreamer\gst\gstelementfactory.c: line 263: assertion
`g_type_is_a (type, GST_TYPE_ELEMENT)' failed
Googling revealed that errors of this kind usually take place when there is
a version mismatch between glib and its derivatives such as gst.
Well... usually, but not always I just learned.
2. when sizeof(element) got over 66K my element was "successfully" created,
but because the size of it was presumed to be around 2K (16 bit truncation),
using my internal data resulted in the whole thing crashing rather quick.
I have a question. Am I the only one who thinks that 16 bit object size
limitation is misplaced in 21st century?
I remember working on 16 bit computers back in early 80s, but with gobject
being a late 90th child, this seems rather strange. Is there a good reason
for this limitation?
Personally when I have to deal with this on a server that has GIGs of free
memory, I turn to get grumpy. Sure, I can work around it, but it requires me
to put out a bit of a code that makes everything less reliable.
I know I should probably take this up to glib folks, but I was wondering if
someone here might know that answer.
Thanks for letting me vent.
-- Max.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Locked
