OAH Build

g_printf doesn't work correctly.

Asked by ablmf@hotmail.com

I've compiled a oah build of glib. I found that it crash on g_printf("%s", NULL) because it uses "strlen", and strlen(0) would crash. The compiled version I downloaded here and the version I got from gtk site don't have that problem. What's the problem?

Here is the call stack:

ChildEBP RetAddr Args to Child
0021da24 02980d67 00000000 73007325 00000000 MSVCR90!strlen+0x30
0021dd60 02966cd7 0021dd7c 0021e208 00000000 libglib_2_0!_g_gnulib_vasnprintf+0x424 [e:\software\glib\oah-glib-2.19.2src\glib\gnulib\vasnprintf.c @ 581]
0021dd74 02971c32 0021dd8c 028aa048 0021e208 libglib_2_0!g_vasprintf+0x1a [e:\software\glib\oah-glib-2.19.2src\glib\gprintf.c @ 309]
0021dd90 029629f0 028aa048 0021e208 0021e2dc libglib_2_0!g_strdup_vprintf+0x18 [e:\software\glib\oah-glib-2.19.2src\glib\gstrfuncs.c @ 220]
0021e1d8 02962a9c 00000000 00000080 028aa048 libglib_2_0!g_logv+0x1eb [e:\software\glib\oah-glib-2.19.2src\glib\gmessages.c @ 474]
0021e1f4 02717f71 00000000 00000080 028aa048 libglib_2_0!g_log+0x18 [e:\software\glib\oah-glib-2.19.2src\glib\gmessages.c @ 517]
0021e2dc 02718766 01c73000 028b2aa0 0021e3ac vivs_core!vivs_filmcompany_query_valist+0x121 [g:\code\vivs\code\trunk\sdk\vivs_core\vivs_filmcompany.cpp @ 461]
0021e350 0272e902 01c73000 028b2aa0 0021e3ac vivs_core!vivs_filmcompany_query+0x106 [g:\code\vivs\code\trunk\sdk\vivs_core\vivs_filmcompany.cpp @ 605]
0021e3b4 0272df60 01c6d180 00d72c38 cccccccc vivs_core!vivs_theatre_open_band+0xe2 [g:\code\vivs\code\trunk\sdk\vivs_core\music\vivs_theatre.cpp @ 503]
0021e3dc 1d1aaee2 01c6d180 01c350fc 00360a2a vivs_core!vivs_theatre_open_concert+0x120 [g:\code\vivs\code\trunk\sdk\vivs_core\music\vivs_theatre.cpp @ 334]
WARNING: Stack unwind information not available. Following frames may be wrong.
0021e3f8 1d1aa026 1d1a9eca 0021e418 00000010 _ctypes!DllCanUnloadNow+0x432e
0021e424 1d1a737a 0270231c 0021e510 0021e4f0 _ctypes!DllCanUnloadNow+0x3472
0021e4cc 1d1a79a6 00001101 0270231c 0021e500 _ctypes!DllCanUnloadNow+0x7c6
0021e598 1d1a4566 0270231c 00000000 00000000 _ctypes!DllCanUnloadNow+0xdf2
0021e5f0 1e01480f 00000000 00d295d0 00000000 _ctypes+0x4566
0021e608 1e010a32 00e17c60 00d295d0 00000000 python26!PyObject_Call+0x3f
0021e634 1e01106f 00d295d0 0021e788 00da94d8 python26!PyEval_EvalCodeEx+0x822
00000000 00000000 00000000 00000000 00000000 python26!PyEval_EvalFrameEx+0x3ff

Question information

Language:
English Edit question
Status:
Solved
For:
OAH Build Edit question
Assignee:
No assignee Edit question
Solved by:
ablmf@hotmail.com
Solved:
Last query:
Last reply:
Revision history for this message
ablmf@hotmail.com (ablmf) said : 		#1

Many many code in glib depends on that g_log doesn't crash on null parameter. So the version I compiled could not work anyway.

BTW : I am compiling glib with code : http://launchpad.net/oah/glib/2.19.2/+download/oah-glib-2.19.2src.zip

Revision history for this message
ablmf@hotmail.com (ablmf) said : 		#2

I will try download from the source, it really hard to do that at my office.

Revision history for this message
Haakon Sporsheim (ieei) said : 		#3

Hi... could you open a bug instead? Anyway, I don't think I have time to look at this right now, so if you come up with a patch, I will be glad to apply it!

Revision history for this message
ablmf@hotmail.com (ablmf) said : 		#4

OH, it's not a bug of glib. Somewhere in the code used complete port to operate a file asynchronously, it made a mistake, that caused the problem.