Bug #68201 query_print will cause core dump in 32-bit application
Submitted: 28 Jan 2013 8:55 Modified: 11 Mar 2013 17:28
Reporter: Nan Xiao Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S1 (Critical)
Version:5.2.3 OS:Solaris
Assigned to: Bogdan Degtyariov
Tags: 32-bit, query_print

[28 Jan 2013 8:55] Nan Xiao
Description:
Hi, all:

	the implementation of query_print(Utility.c) function:
	{
    	  if ( log_file && query )
    	  {
            fprintf(log_file, "%lld:%s;\n", time(NULL), query);
    	  }
        }
        
        In 32-bit application,
        
        sizeof(long long) is 8 bytes;
        sizeof(long) is 4 bytes;
        
        The return value's length of time(NULl) is 4 bytes, so the function will core dump.
        
        I think the implementation should be:
        {
    	  if ( log_file && query )
    	  {
            fprintf(log_file, "%ld:%s;\n", time(NULL), query);
    	  }
        }
        
        Thanks very much!
 
 Best Regards
 Nan Xiao

How to repeat:
Open the log file for Connector/ODBC:
[Driver]
option=524292
[29 Jan 2013 8:12] Bogdan Degtyariov
Nan,

thanks for reporting the problem in Connector/ODBC.
You are right - the crash can occur when the result of time(NULL) is 32-bit.
However, in some OS such as Windows 64-bit we have to deal with 64-bit result for time(NULL), so the solution should be slightly different (this is a very minor detail comparing to the research you did for the problem, so thanks again).
[29 Jan 2013 8:23] Nan Xiao
Hi, Bogdan:

    I think long is OK for time(NULL)'s return value for both 32-bit or 64-bit application.
    For 32-bit application: sizeof(long) is 4;
    For 64-bit application: sizeof(long) is 8;
    So %ld is OK for time(NULL), is it right?

Best Regards
Nan Xiao
[29 Jan 2013 9:14] Bogdan Degtyariov
Nan,

not quite so, here is the inline code for windows time function, as you can see it returns 64-bit value:

static __inline time_t __CRTDECL time(time_t * _Time)
{
    return _time64(_Time);
}

32-bits will be returned only when _USE_32BIT_TIME_T is defined.
[29 Jan 2013 9:37] Nan Xiao
Hi, Bogdan:

    Got it, thanks very much for your patient explanation! You can close the issue now, and look forwarding your new release for Connector/ODBC.

    BTW, I also submitted a bug yesterday: http://bugs.mysql.com/bug.php?id=68195. If you have time, could you help to give some comments on this issue? Thanks in advance!

Best Regards
Nan Xiao
[27 Feb 2013 5:49] Bogdan Degtyariov
patch

Attachment: bug68201_v2.diff (application/octet-stream, text), 826 bytes.

[27 Feb 2013 10:58] Bogdan Degtyariov
The patch has been pushed into the revision 1121
[28 Feb 2013 6:26] Nan Xiao
Hi, Bogdan:

	Thanks very much for your patient replies in these days!
	
	I have summarized some questions:
	
	(1) For bug 68195(core dump in my_thread_name function issue), I think it is a MySQL bug, and you will fix it in future. Is it right?
	(2) Regarding to bug 68196, I will wait for your feedback;
	(3) I find in my Solaris 10 environments,
	
	    When unixODBC and MyODBC driver are dynamically linked with ltdl library, sometimes the application will connect MySQL error.
	    But When unixODBC and MyODBC driver aren't dynamically linked with ltdl library, the application runs always well.
	    
	    I am not very sure whether there is a relation with ltdl library. I have sent related logs to Nick(unixODBC leader), and hav't get response from him.
	    Does the linking ltdl library method affect MyODBC driver?
	    
	Thanks very much in advance!

Best Regards
Nan Xiao
[28 Feb 2013 9:46] Bogdan Degtyariov
Hi Nan,

Can you please do not put here the questions that are not directly related to the bug itself? It creates mess, which is very hard to deal with.

I will answer your questions about ltdl in bug 68195.
Thanks.
[6 Mar 2013 8:43] Nan Xiao
Hi, Bogdan:

    Very sorry for my behavior!
    You can close the issue, thanks for your patience and reply!

Best Regards
Nan Xiao
[11 Mar 2013 17:28] John Russell
Added to changelog for 5.2.5: 

The query_print() function could cause a serious error on 32-bit
systems due to a 32-bit / 64-bit mismatch in its return value. This
error could occur when logging was enabled, for example when using
configuration settings such as:

[Driver]
option=524292