I found a problem that caused the pointer sent to memcpy to be
unaddressable only on 64bit big endian systems. This function has some
arguments backwards and this results in casiting a pointer to an int and
then back to a char* later giving an invalid address in the
"lib_mod_event" callback. I've corrected the arguments to the function,
and the call to the callback.
This function is static and therefore has no declaration in a header,
which may be why it evaded detection.
I think this change belongs in the products source but I'm not a CVS
committer so its up to someone greater than me...
Please send me some feedback about this.
Wendell Nichols
Before my change:
static int APP_CC
xrdp_wm_process_channel_data(struct xrdp_wm* self, int channel_id,
char* data, int data_len)
{
if (self->mm->mod != 0)
{
if (self->mm->mod->mod_event != 0)
{
self->mm->mod->mod_event(self->mm->mod, 0x5555, channel_id,
(long)data,
data_len, 0);
}
}
return 0;
}
After my change:
/******************************************************************************/
static int APP_CC
xrdp_wm_process_channel_data(struct xrdp_wm* self, int channel_id,
int data_len, char*data)
{
if (self->mm->mod != 0)
{
if (self->mm->mod->mod_event != 0)
{
self->mm->mod->mod_event(self->mm->mod, 0x5555, channel_id,
(long)data_len,
data, 0);
}
}
return 0;
}
I found a "fix" for this but I cannot explain why it is working as it is:
In vnc.c the function
int DEFAULT_CC
lib_mod_event(struct vnc* v, int msg, long param1, long param2,
long param3, long param4)
{
gets called with different arguments on my x86 linux box vs my zLinux
os390 box:
on zlinux the size is in param3 and data is in param4. On x86 its the
other way around. I swapped the way the parms were used on zlinux to
mkake it work and it does work but I don't see why there is a
difference. I'll have to get both systems breakstopped and th
On 03/17/2010 11:05 AM, Wendell Nichols wrote:
> I compiled xrdp on a zlinux (system 390 platform) system. It builds and
> installs ok but just as your session is about to come up xrdp
> segfaults. The segfault happens in the second thread of the xrdp
> process. The stack is 2 deep:
>
> Thread [2] (Suspended: Signal 'SIGSEGV' received. Description:
> Segmentation fault.)
> 2 g_memcpy()
> /mftdev/dev/wcn/src/zlinux/weed/xrdp-0.4.1/common/os_calls.c:215
> 0x000000008001a954
> 1<symbol is not available> 0x00000200000262a8
>
> and the second arg to g_memcpy is a bad pointer: 0xffffffff8002e1df.
> looks like some one casted an int to a pointer and used it as an arg,
> but the function at level 1 of the stack doesn't have any debug info
> available so I suspect its from some other lib? Not sure how its
> calling this function directly.. but I've not looked at the code much.
>
> This machine doesn't do 32 bit mode, (it does 31 bit mode which is
> usually a problem for linux software) so I'd rather get it working in 64
> bit mode. any ideas?
> wcn
>
> p.s. please copy wc...@shaw.ca
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
xrdp-devel mailing list
xrdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xrdp-devel
