Re: [gst-embedded] gstreamer segfault on ARM

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [gst-embedded] gstreamer segfault on ARM

Bernard Blackham-4
[Taking to gst-devel]

Bernard Blackham wrote:

> Running a rather simple program:
>
>   #include <gst/gst.h>
>   int main() {
>     gst_init(0, NULL);
>     g_pipeline_new("pipeline");
>     return 0;
>   }
>
> with GST_DEBUG=4 causes the program to segfault when it goes to
> print out one of its trace messages.

I tracked down the cause of this to an incompatibility with my build of
glib. When cross-compiling glib, it decided to not like glibc's printf
(because it tried running some printf tests and failed, because it was
cross-compiling), and thus went and used its own printf implementation.

Gstreamer was not aware of this decision in the glib build though, so it
happily went ahead and used glib assuming it had a glibc printf that
could support printf extensions (that it uses to format %P in strings).

Rebuilding glib with the right configure cache settings (below) solved
the gstreamer crash.

  glib_cv_long_long_format=ll
  ac_cv_func_printf_unix98=yes
  ac_cv_func_vsnprintf_c99=yes

So this solved the problem, but I'm wondering if there should be a
better way for gstreamer to detect if it is safe to use %P or not: not
only does glibc need to provide it, but glib needs to be using it too.
Or is the fact that glibc provides it enough proof that glib should be
using it and anything else is a broken setup like mine was?

TIA,
Bernard.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gst-embedded] gstreamer segfault on ARM

Shi Ling-w20230
Zhao Liang,
I remember we meet the same issue before. Could you check?




Shi Ling
Tel:86-10-84733539
Motorola (China) Technology Ltd.
No.1 Wang Jing East Road, Chao Yang District, 100102 Beijing

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
Bernard Blackham
Sent: Friday, June 20, 2008 3:30 PM
To: [hidden email];
[hidden email]
Subject: Re: [gst-devel] [gst-embedded] gstreamer segfault on ARM

[Taking to gst-devel]

Bernard Blackham wrote:

> Running a rather simple program:
>
>   #include <gst/gst.h>
>   int main() {
>     gst_init(0, NULL);
>     g_pipeline_new("pipeline");
>     return 0;
>   }
>
> with GST_DEBUG=4 causes the program to segfault when it goes to
> print out one of its trace messages.

I tracked down the cause of this to an incompatibility with my build of
glib. When cross-compiling glib, it decided to not like glibc's printf
(because it tried running some printf tests and failed, because it was
cross-compiling), and thus went and used its own printf implementation.

Gstreamer was not aware of this decision in the glib build though, so it

happily went ahead and used glib assuming it had a glibc printf that
could support printf extensions (that it uses to format %P in strings).

Rebuilding glib with the right configure cache settings (below) solved
the gstreamer crash.

  glib_cv_long_long_format=ll
  ac_cv_func_printf_unix98=yes
  ac_cv_func_vsnprintf_c99=yes

So this solved the problem, but I'm wondering if there should be a
better way for gstreamer to detect if it is safe to use %P or not: not
only does glibc need to provide it, but glib needs to be using it too.
Or is the fact that glibc provides it enough proof that glib should be
using it and anything else is a broken setup like mine was?

TIA,
Bernard.


------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gst-embedded] gstreamer segfault on ARM

LIANG ZHAO-2
Yes, It is same issue with us, but we are using another solution, I can try his fix .


Best Regards
Zhao Liang 赵 亮
Tel:86-10-84733698
No.1 Wang Jing East Road, Chao Yang District, Beijing, China 100102
北京市朝阳区望京东路1号, 100102

-----Original Message-----
From: Shi Ling-w20230
Sent: Monday, June 23, 2008 3:29 PM
To: Bernard Blackham; [hidden email]; [hidden email]; Zhao Liang-E3423C
Subject: RE: [gst-devel] [gst-embedded] gstreamer segfault on ARM

Zhao Liang,
I remember we meet the same issue before. Could you check?




Shi Ling
Tel:86-10-84733539
Motorola (China) Technology Ltd.
No.1 Wang Jing East Road, Chao Yang District, 100102 Beijing

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bernard Blackham
Sent: Friday, June 20, 2008 3:30 PM
To: [hidden email]; [hidden email]
Subject: Re: [gst-devel] [gst-embedded] gstreamer segfault on ARM

[Taking to gst-devel]

Bernard Blackham wrote:

> Running a rather simple program:
>
>   #include <gst/gst.h>
>   int main() {
>     gst_init(0, NULL);
>     g_pipeline_new("pipeline");
>     return 0;
>   }
>
> with GST_DEBUG=4 causes the program to segfault when it goes to print
> out one of its trace messages.
I tracked down the cause of this to an incompatibility with my build of glib. When cross-compiling glib, it decided to not like glibc's printf (because it tried running some printf tests and failed, because it was cross-compiling), and thus went and used its own printf implementation.

Gstreamer was not aware of this decision in the glib build though, so it happily went ahead and used glib assuming it had a glibc printf that could support printf extensions (that it uses to format %P in strings).

Rebuilding glib with the right configure cache settings (below) solved the gstreamer crash.

  glib_cv_long_long_format=ll
  ac_cv_func_printf_unix98=yes
  ac_cv_func_vsnprintf_c99=yes

So this solved the problem, but I'm wondering if there should be a better way for gstreamer to detect if it is safe to use %P or not: not only does glibc need to provide it, but glib needs to be using it too.
Or is the fact that glibc provides it enough proof that glib should be using it and anything else is a broken setup like mine was?

TIA,
Bernard.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gst-embedded] gstreamer segfault on ARM

Liu, Bin
I had the same issue. I manually modified gstconfig.h to make it work. Glib is out of my control.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Zhao Liang-E3423C
Sent: Monday, June 23, 2008 2:34 AM
To: Shi Ling-w20230; Bernard Blackham; [hidden email]; [hidden email]
Subject: Re: [gst-devel] [gst-embedded] gstreamer segfault on ARM

Yes, It is same issue with us, but we are using another solution, I can try his fix .


Best Regards
Zhao Liang 赵 亮
Tel:86-10-84733698
No.1 Wang Jing East Road, Chao Yang District, Beijing, China 100102
北京市朝阳区望京东路1号, 100102

-----Original Message-----
From: Shi Ling-w20230
Sent: Monday, June 23, 2008 3:29 PM
To: Bernard Blackham; [hidden email]; [hidden email]; Zhao Liang-E3423C
Subject: RE: [gst-devel] [gst-embedded] gstreamer segfault on ARM

Zhao Liang,
I remember we meet the same issue before. Could you check?




Shi Ling
Tel:86-10-84733539
Motorola (China) Technology Ltd.
No.1 Wang Jing East Road, Chao Yang District, 100102 Beijing

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bernard Blackham
Sent: Friday, June 20, 2008 3:30 PM
To: [hidden email]; [hidden email]
Subject: Re: [gst-devel] [gst-embedded] gstreamer segfault on ARM

[Taking to gst-devel]

Bernard Blackham wrote:

> Running a rather simple program:
>
>   #include <gst/gst.h>
>   int main() {
>     gst_init(0, NULL);
>     g_pipeline_new("pipeline");
>     return 0;
>   }
>
> with GST_DEBUG=4 causes the program to segfault when it goes to print
> out one of its trace messages.
I tracked down the cause of this to an incompatibility with my build of glib. When cross-compiling glib, it decided to not like glibc's printf (because it tried running some printf tests and failed, because it was cross-compiling), and thus went and used its own printf implementation.

Gstreamer was not aware of this decision in the glib build though, so it happily went ahead and used glib assuming it had a glibc printf that could support printf extensions (that it uses to format %P in strings).

Rebuilding glib with the right configure cache settings (below) solved the gstreamer crash.

  glib_cv_long_long_format=ll
  ac_cv_func_printf_unix98=yes
  ac_cv_func_vsnprintf_c99=yes

So this solved the problem, but I'm wondering if there should be a better way for gstreamer to detect if it is safe to use %P or not: not only does glibc need to provide it, but glib needs to be using it too.
Or is the fact that glibc provides it enough proof that glib should be using it and anything else is a broken setup like mine was?

TIA,
Bernard.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: [gst-embedded] gstreamer segfault on ARM

LIANG ZHAO-2
 
Another walkaround is changing configure.ac, disable printf extension support.

Best Regards
Zhao Liang

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Liu, Bin
Sent: Monday, June 23, 2008 10:42 PM
To: [hidden email]; [hidden email]
Subject: Re: [gst-embedded] [gst-devel] gstreamer segfault on ARM

I had the same issue. I manually modified gstconfig.h to make it work. Glib is out of my control.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Zhao Liang-E3423C
Sent: Monday, June 23, 2008 2:34 AM
To: Shi Ling-w20230; Bernard Blackham; [hidden email]; [hidden email]
Subject: Re: [gst-devel] [gst-embedded] gstreamer segfault on ARM

Yes, It is same issue with us, but we are using another solution, I can try his fix .


Best Regards
Zhao Liang 赵 亮
Tel:86-10-84733698
No.1 Wang Jing East Road, Chao Yang District, Beijing, China 100102
北京市朝阳区望京东路1号, 100102

-----Original Message-----
From: Shi Ling-w20230
Sent: Monday, June 23, 2008 3:29 PM
To: Bernard Blackham; [hidden email]; [hidden email]; Zhao Liang-E3423C
Subject: RE: [gst-devel] [gst-embedded] gstreamer segfault on ARM

Zhao Liang,
I remember we meet the same issue before. Could you check?




Shi Ling
Tel:86-10-84733539
Motorola (China) Technology Ltd.
No.1 Wang Jing East Road, Chao Yang District, 100102 Beijing

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bernard Blackham
Sent: Friday, June 20, 2008 3:30 PM
To: [hidden email]; [hidden email]
Subject: Re: [gst-devel] [gst-embedded] gstreamer segfault on ARM

[Taking to gst-devel]

Bernard Blackham wrote:

> Running a rather simple program:
>
>   #include <gst/gst.h>
>   int main() {
>     gst_init(0, NULL);
>     g_pipeline_new("pipeline");
>     return 0;
>   }
>
> with GST_DEBUG=4 causes the program to segfault when it goes to print
> out one of its trace messages.
I tracked down the cause of this to an incompatibility with my build of glib. When cross-compiling glib, it decided to not like glibc's printf (because it tried running some printf tests and failed, because it was cross-compiling), and thus went and used its own printf implementation.

Gstreamer was not aware of this decision in the glib build though, so it happily went ahead and used glib assuming it had a glibc printf that could support printf extensions (that it uses to format %P in strings).

Rebuilding glib with the right configure cache settings (below) solved the gstreamer crash.

  glib_cv_long_long_format=ll
  ac_cv_func_printf_unix98=yes
  ac_cv_func_vsnprintf_c99=yes

So this solved the problem, but I'm wondering if there should be a better way for gstreamer to detect if it is safe to use %P or not: not only does glibc need to provide it, but glib needs to be using it too.
Or is the fact that glibc provides it enough proof that glib should be using it and anything else is a broken setup like mine was?

TIA,
Bernard.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel