unexpected crash in clang+cc program

[joukj]

Hi all,

I'm have a problem with something that looks to me as a random error (or do
I miss something. It is in code compiled by clang calling code compiled
using CC.

I Have:
VSI C++ V10.1-1 and VSI C x86-64 V7.5-009 (GEM 50XBR) on OpenVMS x86_64 V9.2-2

Below are the relevant code snippets (the full code can be found at:
http://nchrem.tnw.tudelft.nl/openvms/so ... html#cxX11
Below the code you can see the output. It appears that many times the code
performs as expected and than at a certain time it crashes when printing a
char* (if you omit this printf it crashes a few lines after doing serious
work). The address of the char* is the same in both the clang as the CC code.
This makes me wonder why it could be printed in the CC-code just before. Or
with other words: why do I lose information? Is there an explantion?



//calling code compiled with clang
get_string_resource (Display *dpy, char *res_name, char *res_class)
{
XrmValue value;
char *type;
char full_name [1024], full_class [1024];
strcpy (full_name, progname);
strcat (full_name, ".");
strcat (full_name, res_name);
strcpy (full_class, progclass);
strcat (full_class, ".");
strcat (full_class, res_class);
//by a #define this is renamed to cxx_XrmGetResource
if (XrmGetResource (XtDatabase (dpy), full_name, full_class, &type, &value))
{
printf( "returned address : %ld\n" , (long) value.addr );
//sometimes it crashes on next line
printf( "returned string : %s\n" , value.addr );
char *str = (char *) malloc (value.size + 1);
strncpy (str, (char *) value.addr, value.size);
free( value.addr );
str [value.size] = 0;
return str;
}
return 0;
}


//called code compiled with CC
//inlcudes of X-headers omitted in this sample code
#pragma pointer_size 64
typedef struct {
char *option; /* Option abbreviation in argv */
char *specifier; /* Resource specifier */
XrmOptionKind2 argKind; /* Which style of option it is */
XrmOptionKind2 dummy; /* to get the right length */
XPointer value; /* Value to provide if XrmoptionNoArg */
} XrmOptionDescRec2;

Bool cxx_XrmGetResource( XrmDatabase database , _Xconst char* str_name ,
_Xconst char* str_class , char** str_type_return ,
XrmValue2* value_return )
{
size_t ll , ll2;
if ( str_name )
ll = strlen(str_name);
if ( str_class )
ll2 = strlen(str_class);
#pragma pointer_size 32
XrmValue value_return2;
char* str_type_return2;
Bool result;
char* str_name2;
char* str_class2;

if ( str_name )
{
if ( str_name < (char*) 2147483648 )
str_name2 = (char*) str_name;
else
{
str_name2 = (char*) malloc(ll);
strcpy( str_name2 , str_name );
}
}
else
str_name2 = NULL;
if ( str_class )
{
if ( str_class < (char*) 2147483648 )
str_class2 = (char*) str_class;
else
{
str_class2 = (char*) malloc(ll2);
strcpy( str_class2 , str_class );
}
}
else
str_class2 = NULL;
result = XrmGetResource( database , str_name2 , str_class2 ,
&str_type_return2 , &value_return2 );
value_return->addr = value_return2.addr;
value_return->size = value_return2.size;
printf( "adress %ld\n" , value_return->addr );
printf( "string %s\n" , value_return->addr );
str_type_return[0] = str_type_return2;
return result;
}





rumba-jj) mc []crystal.exe
adress 0
string (null)
adress 1210540
string false
returned address : 1210540
returned string : false
adress 729004
string false
returned address : 729004
returned string : false
adress 1210508
string
returned address : 1210508
returned string :
adress 1210764
string default
returned address : 1210764
returned string : default
adress 1210588
string false
returned address : 1210588
returned string : false
adress 0
string (null)
adress 1210812
string black
returned address : 1210812
returned string : black
adress 1211132
string 100
returned address : 1211132
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=800000000000
0000, PC=FFFF83000A442EF7, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$SHR STRLEN.C;1 #3641 00000000802D3EF7 FFFF83000A442EF7
DECC$SHR F_DOPRINT.C;1 #40631 00000000802F25D1 FFFF83000A4615D1
DECC$SHR F_DOPRINT.C;1 #40768 00000000802E87C8 FFFF83000A4577C8
DECC$SHR F_DOPRINT.C;1 #41245 00000000802E7B94 FFFF83000A456B94
DECC$SHR F_DOPRINT.C;1 #41494 00000000802E1178 FFFF83000A450178
crystal RESOURCES #58 0000000000000133 000000008000B5F3
crystal RESOURCES #98 00000000000004C4 000000008000B984
crystal XLOCKMORE #374 0000000000000DB6 0000000080009BB6
crystal SCREENHACK #538 0000000000001E02 0000000080001E02
crystal SCREENHACK #931 0000000000000C34 0000000080000C34
crystal 0 0000000080002898 0000000080002898
PTHREAD$RTL 0 00000000800412DC FFFF83000A10B2DC
PTHREAD$RTL 0 0000000080002316 FFFF83000A0CC316
0 FFFF8300085FC0A6 FFFF8300085FC0A6
DCL 0 00000000800677FB 000000007ADFF7FB
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump

[jreagan]

I'll have to try to make a small stand-alone version using your code segments. I want to look at the generated code.

[joukj]

I forgot to mention that if you compile the CC-part without "/noop" it crashes at the same location at an earlier time.

You can also start from the full version and try to strip it, but I'm afraid that the problem may be "random" and may change by changing the code.

[mjvms27]

Should it be pointed out that in cxx_XrmGetResource(), there
are malloc() calls that don't have the return checked for NULL?
Also, (from what I could see) there didn't seem to be a corresponding
free() call in the function so that could potentially lead to leaks.

I realize those were only snippets and I don't want to start a red herring.

Code: Select all

str_name2 = (char*) malloc(ll);
strcpy( str_name2 , str_name );

Code: Select all

str_class2 = (char*) malloc(ll2);
strcpy( str_class2 , str_class );

The malloc() calls appear to be directly using the results of strlen, without including room for the trailing NUL.

[joukj]

You are right about probable leaking memory, but those mallocs are not the problem that is considered here: info disappearing between cc and clang

[mjvms27]

Code: Select all

size_t ll , ll2;
if ( str_name )
ll = strlen(str_name);
if ( str_class )
ll2 = strlen(str_class);
[...]
str_name2 = (char*) malloc(ll);
strcpy( str_name2 , str_name );

[...]
str_class2 = (char*) malloc(ll2);
strcpy( str_class2 , str_class );

These appear to be buffer overruns though, and that could cause all sort of errors and clobberings.

Possibly corrected with either of these:

Code: Select all

ll = strlen(str_name) + 1;

or:

Code: Select all

str_name2 = (char*) malloc(ll + 1);

The strcpy requires room for the trailing NUL, hence the + 1.

[joukj]

tried, but as I expected it has nothing to do with the original problem, wich still is not solved.