Bug 3644 - __unsafe_string_function_usage_here__ disgnostic in smbd/password.o when using Sun Studio 11 compiler
Summary: __unsafe_string_function_usage_here__ disgnostic in smbd/password.o when usin...
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Build environment (show other bugs)
Version: 3.0.9
Hardware: Sparc Solaris
: P3 normal
Target Milestone: none
Assignee: Tim Potter
QA Contact: Samba QA Contact
Depends on:
Reported: 2006-03-29 08:31 UTC by David S. Collier-Brown
Modified: 2007-08-19 09:12 UTC (History)
1 user (show)

See Also:

Patch (182 bytes, patch)
2006-04-27 03:04 UTC, pavan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David S. Collier-Brown 2006-03-29 08:31:26 UTC
There is also one in smbd/reply.o, as shown by the 
make output:

froggy> make
Using FLAGS =  -I/opt/csw/include -g -D_SAMBA_BUILD_ -I/opt/csw/include  -Iinclude -I/export/home/davecb/projects/samba/SVN/samba-3_0/source/include -I/export/home/davecb/projects/samba/SVN/samba-3_0/source/tdb -I/export/home/davecb/projects/samba/SVN/samba-3_0/source/smbwrapper -I. -I/opt/csw/include -D_LARGEFILE_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DLDAP_DEPRECATED -DSUNOS5 -I/export/home/davecb/projects/samba/SVN/samba-3_0/source -D_SAMBA_BUILD_
      LIBS = -lsendfile -lresolv -lnsl -lsocket -liconv
      LDSHFLAGS = -G -I/opt/csw/include -g -D_SAMBA_BUILD_ -I/opt/csw/include  -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/lib -z combreloc -z text -z ignore -lthread -R/opt/csw/lib -L/opt/csw/lib
      LDFLAGS = -L/opt/csw/lib -R/opt/csw/lib -R/opt/csw/lib/ -R/opt/csw/lib -L/opt/csw/lib -z combreloc -z text -z ignore -lthread -R/opt/csw/lib -L/opt/csw/lib
      PIE_CFLAGS =
Compiling smbd/password.c
Compiling smbd/reply.c
Linking bin/smbd
Undefined                       first referenced
 symbol                             in file
__unsafe_string_function_usage_here__ smbd/password.o
__unsafe_string_function_usage_here_size_t__ smbd/reply.o
ld: fatal: Symbol referencing errors. No output written to bin/smbd

Looking at smbd/password.c, I hacked safe_string to see
wherever it might be occurring, but got a whole list of calls
fstrcpy, such as:

"smbd/password.c", line 224: undefined symbol: safe_strcpy_fn2
was the diagnostic my hack generated, which was the line
   fstrcpy(vuser->user.unix_name, server_info->unix_name);

The other lines I found as possibles were also fstrcpys, 
"smbd/password.c", line 224: undefined symbol: safe_strcpy_fn2
"smbd/password.c", line 368: undefined symbol: safe_strcpy_fn2
"smbd/password.c", line 400: undefined symbol: safe_strcat_fn2
"smbd/password.c", line 436: undefined symbol: safe_strcpy_fn2
"smbd/password.c", line 641: undefined symbol: safe_strcpy_fn2
"smbd/password.c", line 656: undefined symbol: safe_strcpy_fn2
"smbd/password.c", line 724: undefined symbol: safe_strcpy_fn2
"smbd/password.c", line 744: undefined symbol: safe_strcpy_fn2
"smbd/password.c", line 778: undefined symbol: safe_strcpy_fn2

CPP says line 224 is the following expanded code, whcih indeed looks like
an fstrcpy...

         ( ( sizeof ( ( vuser -> user . unix_name ) ) != ( sizeof ( fstring ) -
1 + 1 ) && sizeof ( ( vuser -> user . unix_name ) ) != sizeof ( char * ) ) ? __unsafe_string_function_usage_here__ ( ) : safe_strcpy_fn ( ( "" ) , ( 0 ) , ( ( vuser -> user . unix_name ) ) , ( ( server_info -> unix_name ) ) , ( sizeof ( fstring ) - 1 ) ) );

I'll need advice on how to 
- make sure I'm looking at the right line
- debug the problem once I'm sure I have it.

Comment 1 pavan 2006-04-26 02:59:55 UTC

According to my understanding, this error is due to non existent function (i.e function without definition)
in include/safe_string.h. 

In include/safe_string.h,

CHECK_STRING_SIZE macro is defined as,
#define CHECK_STRING_SIZE(d, len) (sizeof(d) != (len) && sizeof(d) != sizeof(char *))

fstrcpy,pstrcpy,fstrcat,pstrcat,pull_string,push_string etc all call macro CHECK_STRING_SIZE.

So when fstrcpy is invoked it makes a macro call, 
CHECK_STRING_SIZE(d,s) ? __unsafe_string_function_usage_here__(): safe_strcpy_fn();

__unsafe_string_function_usage_here__(), __unsafe_string_function_usage_here_size_t__() dont have function definition. 

Linker will not throw any error if condition is always false. 
If result of condition becomes true then __unsafe_string_function_usage_here__() is called, as linker is unable to
resolve call it will throw "unresolved symbol" error linking stage.

For example: 

 when fstrcpy is invoked in "libsmb/cliprint.c" at line number 102, 
 fstrcpy(job.name,fix_char_ptr(SVAL(p,24),converter,rdata, rdrcnt));

name is declared as char name[128] in structure print_job_info "include/libsmbclient.h", 
CHECK_STRING_SIZE returns true, as 128 is not equal to sizeof(fstring) and sizeof(char *),
thus  __unsafe_string_function_usage_here__() is called. Hence the error.

I could think of two ways to solve this issue.

First Solution:

   Undef HAVE_COMPILER_WILL_OPTIMIZE_OUT_FNS this macro in include/config.h

Disabling this macro, will avoid getting into CHECK_STRING_SIZE and hence no linker error.
However this is not a very convincing solution. 

Second Solution

  As the result of CHECK_STRING_SIZE determines the calling of function. Make sure the result of this macro is false. 
I see this macro is used in the samba code for most of the string related functions.

I could see more than 2000 invocations of the string related functions such as pstrcpy, fstrcpy etc. All these function 
calls have to be verified/checked. 

For above example by declaring name as ,
 fstring name; is a solution for only this call. Like this we will have to verify each call. 

Please correct me if I am wrong in my analysis.

Comment 2 pavan 2006-04-26 06:36:45 UTC
 As I am seeing this issue on OSF also the possible patch for bug is,

 Add these lines of code,
 diff safe_string.h safe_string.h.orig
< #if defined(OSF1) || defined(SUNOS5) || defined(SUNOS4)
< #endif

 Let me know if this works on solaris. As this works fine on OSF.

Comment 3 pavan 2006-04-27 03:04:33 UTC
Created attachment 1877 [details]

Hi Dave,
        Can you please try to apply this patch and see if this helps?

Comment 4 David S. Collier-Brown 2007-08-19 09:12:05 UTC
Belatedly, this is now file.

--dave (doing his janitorial cleanup) c-b