Perl module GSSAPI core dumps with kerberos 1.14 - perl
I am trying to compile GSSAPI PERL module with kerberos and I'm getting a core dump while testing it. Here are the details:
GSSAPI version: 0.28
KERBEROS: 1.14
PERL: 5.22
OS: SunOS kangaroo 5.11 11.2 sun4v sparc sun4v
While running the tests for GSSAPI, I get a core dump
sv_app#kangaroo:…rc/trunk/perl-5.22/GSSAPI-0.28$ make test
PERL_DL_NONLAZY=1 "/u01/sv/app/10.00/perl/product/perl-5.22.0/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/1constants.t ..... ok
t/2status.t ........ ok
t/checkoids.t ...... ok
t/importnames.t .... ok
t/indicatemechs.t .. 1/5 # KRB5 old Mechtype, Kerberos 5, SPNEGO
t/indicatemechs.t .. ok
t/inquire_cred.t ... Failed 6/6 subtests
t/pod.t ............ skipped: Test::Pod 1.00 required for testing POD
t/test.t ........... ok
t/zbugfixes.t ...... 1/3 #
Stack Trace from core dump:
t#1 (l#1) program terminated by signal BUS (invalid address alignment)
0x0007fffefcbec2d0: get_value_vt+0x0010: ldx [%i3 + 8], %i1
(dbx) where
current thread: t#1
=>[1] get_value_vt(0x1006b9ca0, 0xffffffff7fffe7d0, 0xffffffff7fffe7c8, 0x11, 0x0, 0x0), at 0x7fffefcbec2d0
[2] profile_get_string(0x1006b9ca0, 0x7fffefcbf9ab0, 0x7fffefcbf9b08, 0x0, 0x0, 0xffffffff7fffe8a8), at 0x7fffefcbec420
[3] k5_kt_client_default_name(0x1003746b0, 0xffffffff7fffe968, 0x0, 0x0, 0xffffffffffed59e8, 0x12a400), at 0x7fffefcbd50b0
[4] krb5_kt_client_default(0x1003746b0, 0x1005734a0, 0xffffffff7fffeafc, 0x0, 0xffffffff7fffef8c, 0x0), at 0x7fffefcb63678
[5] acquire_init_cred(0x1003746b0, 0xffffffff7fffef8c, 0x0, 0x0, 0x0, 0x100573450), at 0x7fffefd53c878
[6] acquire_cred_context(0x1003746b0, 0xffffffff7fffef8c, 0x0, 0x0, 0x100573450, 0x1), at 0x7fffefd53cc04
[7] krb5_gss_acquire_cred_from(0x0, 0x0, 0x78, 0x0, 0x1, 0x0), at 0x7fffefd53d880
[8] gss_add_cred_from(0xffffffff7fffef8c, 0x100362470, 0x78, 0x100362410, 0x100362470, 0x0), at 0x7fffefd51d61c
[9] gss_acquire_cred_from(0xffffffff7ffff188, 0x0, 0x1, 0x0, 0xffffffff7fffefd0, 0x0), at 0x7fffefd51cf50
[10] gss_acquire_cred(0xffffffff7ffff188, 0x0, 0x78, 0x0, 0x1, 0xffffffff7ffff198), at 0x7fffefd51cb84
[11] XS_GSSAPI__Cred_acquire_cred(0x28, 0x0, 0x0, 0x38, 0x30, 0x8), at 0x7fffefd808a08
[12] Perl_pp_entersub(0x38, 0x2, 0x20000, 0x1004b3310, 0x100000, 0x7), at 0x100116408
[13] Perl_runops_standard(0x100169260, 0x1006ca470, 0x1006ca470, 0x10034c000, 0x10034c, 0x10034c5e0), at 0x100109c04
[14] S_run_body(0x100000, 0x10034c, 0x10034c, 0x0, 0x0, 0x10034d460), at 0x100054fc0
[15] perl_run(0x10034d, 0xffffffff7ffff488, 0x100000, 0x1, 0x0, 0x10034b000), at 0x100054c20
[16] main(0x2, 0xffffffff7ffff6c8, 0x10034b, 0x10034d000, 0x10034b, 0x10034bb80), at 0x1000261f0
(dbx) frame 1
0x0007fffefcbec2d0: get_value_vt+0x0010: ldx [%i3 + 8], %i1
(dbx) regs
current thread: t#1
current frame: [1]
g0-g1 0x0000000000000000 0x0000000000000000
g2-g3 0x0000000000000000 0x0000000000000000
g4-g5 0x000000000000004b 0x0007fffefcbf9af5
g6-g7 0x0000000000000000 0x0007fffefea02a40
o0-o1 0x0000000000000000 0xffffffff7fffe7d0
o2-o3 0xffffffff7fffe708 0x0000000000000000
o4-o5 0x0000000000000000 0x0000000000000000
o6-o7 0xffffffff7fffde51 0x0007fffefcbec368
l0-l1 0x0000000000000000 0x0000000000000000
l2-l3 0x0000000000000000 0x0000000000000000
l4-l5 0x0000000000000000 0x0000000000000000
l6-l7 0x0000000000000000 0x0000000000000011
i0-i1 0x00000001006b9ca0 0xffffffff7fffe7d0
i2-i3 0xffffffff7fffe7c8 0x0000000000000011
i4-i5 0x0000000000000000 0x0000000000000000
i6-i7 0xffffffff7fffdf11 0x0007fffefcbec420
y 0x0000000000000000
ccr 0x0000000000000000
pc 0x0007fffefcbec2d0:get_value_vt+0x10 ldx [%i3 + 8], %i1
npc 0x0007fffefcbec2d4:get_value_vt+0x14 call %i1
(dbx) examine 0xffffffff7fffe7d0/i
0xffffffff7fffe7d0: illtrap 0x7fffe
krb5-1.14/src/util/profile/prof_get.c
/* Look up a relation in a vtable profile and return the first value in the
* result. */
static errcode_t
get_value_vt(profile_t profile, const char *const *names, char **ret_value)
{
errcode_t retval;
char **vtvalues;
retval = profile->vt->get_values(profile->cbdata, names, &vtvalues);
if (retval)
return retval;
*ret_value = strdup(*vtvalues);
if (*ret_value == NULL)
retval = ENOMEM;
profile->vt->free_values(profile->cbdata, vtvalues);
return retval;
}
Related
unable to handle kernel paging request at [address]
**
[ 105.823895] BUG: unable to handle kernel paging request at ffffffffc06ed026
[ 105.823899] PGD 13c80e067 P4D 13c80e067 PUD 13c810067 PMD 12f1d0067 PTE 0
[ 105.823901] Oops: 0010 [#1] SMP NOPTI
[ 105.823903] CPU: 2 PID: 2935 Comm: bash Tainted: G OE 4.19.67-2018202030 #7
[ 105.823904] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 105.823907] RIP: 0010:0xffffffffc06ed026
[ 105.823910] Code: Bad RIP value.
[ 105.823910] RSP: 0018:ffffb129843cbf28 EFLAGS: 00010286
[ 105.823911] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffff8e4e001cb900
[ 105.823912] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8e4e2918f2d8
[ 105.823913] RBP: ffffb129843cbf28 R08: 0000000000000000 R09: 0000000000000000
[ 105.823913] R10: ffffb129843cbe98 R11: 0000000000000000 R12: ffffb129843cbf58
[ 105.823914] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 105.823915] FS: 00007fd974ed2700(0000) GS:ffff8e4e3de80000(0000) knlGS:0000000000000000
[ 105.823915] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 105.823916] CR2: ffffffffc06ecffc CR3: 00000000b5d0e000 CR4: 0000000000340ee0
[ 105.823932] Call Trace:
[ 105.823938] do_syscall_64+0x5a/0x110
[ 105.823941] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 105.823942] RIP: 0033:0x7fd9745c6360
[ 105.823943] Code: 0b 31 c0 48 83 c4 08 e9 ae fe ff ff 48 8d 3d 27 b4 09 00 e8 b2 1e 02 00 66 90 83 3d e9 23 2d 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 5e de 01 00 48 89 04 24
[ 105.823944] RSP: 002b:00007ffeb6b5eb98 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 105.823945] RAX: ffffffffffffffda RBX: 00007fd9748938e0 RCX: 00007fd9745c6360
[ 105.823946] RDX: 0000000000000001 RSI: 00007ffeb6b5eba7 RDI: 0000000000000000
[ 105.823946] RBP: 00000000004d7d4a R08: 00007fd974895770 R09: 00007fd974ed2700
[ 105.823947] R10: 662f37362e39312e R11: 0000000000000246 R12: 000000000045f7d0
[ 105.823947] R13: 0000000000000001 R14: 0000000000000000 R15: 00007ffeb6b5ed60
[ 105.823948] Modules linked in: rfcomm bnep snd_ens1371 snd_ac97_codec gameport ac97_bus btusb btrtl snd_pcm crct10dif_pclmul snd_seq_midi snd_seq_midi_event crc32_pclmul ghash_clmulni_intel snd_rawmidi vmw_balloon pcbc snd_seq snd_seq_device snd_timer btbcm btintel snd bluetooth aesni_intel aes_x86_64 crypto_simd cryptd glue_helper input_leds joydev serio_raw soundcore ecdh_generic i2c_piix4 mac_hid vmw_vsock_vmci_transport vsock vmw_vmci parport_pc ppdev lp parport autofs4 hid_generic usbhid hid vmwgfx ttm drm_kms_helper mptspi mptscsih syscopyarea sysfillrect mptbase sysimgblt fb_sys_fops drm psmouse e1000 scsi_transport_spi ahci libahci pata_acpi [last unloaded: ftracehooking]
[ 105.823975] CR2: ffffffffc06ed026
[ 105.823976] ---[ end trace 2530693e2a17bef8 ]---
[ 105.823977] RIP: 0010:0xffffffffc06ed026
[ 105.823978] Code: Bad RIP value.
[ 105.823979] RSP: 0018:ffffb129843cbf28 EFLAGS: 00010286
[ 105.823980] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffff8e4e001cb900
[ 105.823980] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8e4e2918f2d8
[ 105.823981] RBP: ffffb129843cbf28 R08: 0000000000000000 R09: 0000000000000000
[ 105.823981] R10: ffffb129843cbe98 R11: 0000000000000000 R12: ffffb129843cbf58
[ 105.823982] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 105.823983] FS: 00007fd974ed2700(0000) GS:ffff8e4e3de80000(0000) knlGS:0000000000000000
[ 105.823983] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 105.823984] CR2: ffffffffc06ecffc CR3: 00000000b5d0e000 CR4: 0000000000340ee0
[ 105.829428] BUG: unable to handle kernel paging request at ffffffffc06ed026
[ 105.829433] PGD 13c80e067 P4D 13c80e067 PUD 13c810067 PMD 12f1d0067 PTE 0
[ 105.829439] Oops: 0010 [#2] SMP NOPTI
[ 105.829442] CPU: 1 PID: 1024 Comm: in:imklog Tainted: G D OE 4.19.67-2018202030 #7
[ 105.829444] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[ 105.829450] RIP: 0010:0xffffffffc06ed026
[ 105.829455] Code: Bad RIP value.
[ 105.829456] RSP: 0018:ffffb12981b6bf28 EFLAGS: 00010286
[ 105.829459] RAX: 0000000000000ea7 RBX: 0000000000000000 RCX: 0000000000000000
[ 105.829460] RDX: ffff8e4e0003ae00 RSI: 0000000000000000 RDI: ffff8e4d979eb200
[ 105.829461] RBP: ffffb12981b6bf28 R08: 0000000000000000 R09: 0000000000000000
[ 105.829463] R10: ffffb12981b6be98 R11: ffff8e4e3d806e80 R12: ffffb12981b6bf58
[ 105.829464] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 105.829466] FS: 00007f3d4182d700(0000) GS:ffff8e4e3de40000(0000) knlGS:0000000000000000
[ 105.829468] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 105.829469] CR2: ffffffffc06ecffc CR3: 0000000134a30000 CR4: 0000000000340ee0
[ 105.829496] Call Trace:
[ 105.829505] do_syscall_64+0x5a/0x110
[ 105.829510] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 105.829512] RIP: 0033:0x7f3d43c7c51d
[ 105.829515] Code: be 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 4e fc ff ff 48 89 04 24 b8 00 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 97 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
[ 105.829516] RSP: 002b:00007f3d4180c580 EFLAGS: 00000293 ORIG_RAX: 0000000000000000
[ 105.829518] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3d43c7c51d
[ 105.829520] RDX: 0000000000001fa0 RSI: 00007f3d4180cda0 RDI: 0000000000000004
[ 105.829521] RBP: 00000000011c8320 R08: 0000000000000000 R09: 0000000000000000
[ 105.829522] R10: 00007f3d4180c3d0 R11: 0000000000000293 R12: 00007f3d4180cda0
[ 105.829524] R13: 0000000000001fa0 R14: 0000000000001f9f R15: 00007f3d4180ce98
[ 105.829526] Modules linked in: rfcomm bnep snd_ens1371 snd_ac97_codec gameport ac97_bus btusb btrtl snd_pcm crct10dif_pclmul snd_seq_midi snd_seq_midi_event crc32_pclmul ghash_clmulni_intel snd_rawmidi vmw_balloon pcbc snd_seq snd_seq_device snd_timer btbcm btintel snd bluetooth aesni_intel aes_x86_64 crypto_simd cryptd glue_helper input_leds joydev serio_raw soundcore ecdh_generic i2c_piix4 mac_hid vmw_vsock_vmci_transport vsock vmw_vmci parport_pc ppdev lp parport autofs4 hid_generic usbhid hid vmwgfx ttm drm_kms_helper mptspi mptscsih syscopyarea sysfillrect mptbase sysimgblt fb_sys_fops drm psmouse e1000 scsi_transport_spi ahci libahci pata_acpi [last unloaded: ftracehooking]
[ 105.829632] CR2: ffffffffc06ed026
[ 105.829635] ---[ end trace 2530693e2a17bef9 ]---
[ 105.829638] RIP: 0010:0xffffffffc06ed026
[ 105.829641] Code: Bad RIP value.
[ 105.829643] RSP: 0018:ffffb129843cbf28 EFLAGS: 00010286
[ 105.829644] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffff8e4e001cb900
[ 105.829646] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8e4e2918f2d8
[ 105.829647] RBP: ffffb129843cbf28 R08: 0000000000000000 R09: 0000000000000000
[ 105.829648] R10: ffffb129843cbe98 R11: 0000000000000000 R12: ffffb129843cbf58
[ 105.829649] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 105.829651] FS: 00007f3d4182d700(0000) GS:ffff8e4e3de40000(0000) knlGS:0000000000000000
[ 105.829653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 105.829654] CR2: ffffffffc06ecffc CR3: 0000000134a30000 CR4: 0000000000340ee0
os2018202030#ubuntu:~$**
I learning operating systems. I made a system call hooking and I found that it has a problem with removing it.
Although the system call hooking I made works fine. But when I remove the module from the kernel, it gives this kind of error message. I assume this kind of error is related to the page size of "syscall_table", but I can't find any relation between "syscall_table" and the address that the error message gave me. (I printed syscall_table address, gave me an address starting with 0000XXXXXX.)
those are the header files that I include.
#include <linux/module.h>
#include <linux/highmem.h>
#include <linux/kallsyms.h>
#include <linux/syscalls.h>
#include <asm/syscall_wrapper.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/version.h>
#include <linux/namei.h>
#include <linux/sched.h>
those are codes that I've written.
#include "./ftracehooking.h"
#define __NR_ftrace 336 //trace system call identifier
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jiyong Park");
MODULE_DESCRIPTION("ftrace hook");
MODULE_VERSION("0.1");
/*
trace variables
*/
int read_count = 0;
int read_bytes = 0;
int write_count = 0;
int write_bytes = 0;
int open_count = 0;
char open_file[NAME_MAX] = {0 };
int close_count = 0;
int lseek_count = 0;
/*
make trace variables accessable from dynamically inserted modules
*/
EXPORT_SYMBOL(read_count);
EXPORT_SYMBOL(read_bytes);
EXPORT_SYMBOL(write_count);
EXPORT_SYMBOL(write_bytes);
EXPORT_SYMBOL(open_count);
EXPORT_SYMBOL(open_file);
EXPORT_SYMBOL(close_count);
EXPORT_SYMBOL(lseek_count);
void **syscall_table; //pointer to syscall table
static asmlinkage int (* orig_ftrace)(const struct pt_regs *reg); //a pointer to original syscall
static asmlinkage int hook_ftrace(const struct pt_regs *reg) //a ftrace hooking syscall
{
pid_t pid = reg->di; //get first argument of the pt_regs structure
if(pid != 0) //if current process is parent process whose pid is not 0
{
/*
initialize variables
*/
read_count = 0;
read_bytes = 0;
write_count = 0;
write_bytes = 0;
open_count = 0;
open_file[0] = '\0';
close_count = 0;
lseek_count = 0;
printk(KERN_INFO "OS Assignment2 ftrace [%d] Start\n", pid); //print kernel message
}
else
{
/*
if it is child process whose pid is 0, print kernel message below
we can get current file name from task_struct *current
*/
printk(KERN_INFO "[2018202030] %s file[%s] start [x] read - %d / written - %d\n", current->comm, open_file, read_bytes, write_bytes);
printk(KERN_INFO "open[%d] close[%d] read[%d] write[%d] lseek[%d]\n", open_count, close_count, read_count, write_count, lseek_count);
printk(KERN_INFO "OS Assignment2 ftrace [%d] End\n", pid);
}
return orig_ftrace(reg); //call original ftrace syscall and return its return value
}
/*
get read and write permission at address
*/
void make_rw(void *addr)
{
unsigned int level;
pte_t *pte = lookup_address((u64)addr, &level); //get page table entry of address
if(pte->pte &~ _PAGE_RW) //if there is no write permission on the address
pte->pte |= _PAGE_RW; //turn on read write permission
}
/*
retrieve read only permission at address
*/
void make_ro(void *addr)
{
unsigned int level;
pte_t *pte = lookup_address((u64)addr, &level); //get page table entry of address
pte->pte = pte->pte &~ _PAGE_RW; //eliminate write permission
}
static int __init hooking_init(void)
{
syscall_table = (void **)kallsyms_lookup_name("sys_call_table"); //get syscall table entry
make_rw(syscall_table); //get page write permission
orig_ftrace = syscall_table[__NR_ftrace]; //store original ftrace syscall
syscall_table[__NR_ftrace] = hook_ftrace; //hook a user defined syscall
make_ro(syscall_table); //eliminate page write permission
return 0;
}
static void __exit hooking_exit(void)
{
make_rw(syscall_table); //get page write permission
syscall_table[__NR_ftrace] = orig_ftrace; //restore pre-defined syscall
make_ro(syscall_table); //eliminate page write permission
}
module_init(hooking_init); //insert module
module_exit(hooking_exit); //exit module
#include "./ftracehooking.h"
#define __NR_ftrace 336
#define __NR_read 0
#define __NR_write 1
#define __NR_open 2
#define __NR_close 3
#define __NR_lseek 8
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jiyong Park");
MODULE_DESCRIPTION("io trace hook");
MODULE_VERSION("0.1");
void **syscall_table; //pointer to syscall table
/*
external trace variables
*/
extern int read_count;
extern int read_bytes;
extern int write_count;
extern int write_bytes;
extern int open_count;
extern char open_file[NAME_MAX];
extern int close_count;
extern int lseek_count;
/*
pointers to original syscall
*/
static asmlinkage long (*orig_read)(const struct pt_regs *);
static asmlinkage long (*orig_write)(const struct pt_regs *);
static asmlinkage long (*orig_open)(const struct pt_regs *);
static asmlinkage long (*orig_close)(const struct pt_regs *);
static asmlinkage long (*orig_lseek)(const struct pt_regs *);
static asmlinkage long ftrace_read(const struct pt_regs *reg) //read syscall hook
{
read_bytes += reg->dx; //get third argument of the pt_regs structure
++read_count; //increase read count
return orig_read(reg); //call original read syscall and return its return value
}
static asmlinkage long ftrace_write(const struct pt_regs *reg) //write syscall hook
{
write_bytes += reg->dx; //get third argument of the pt_regs structure
++write_count; //increase write count
return orig_write(reg); //call original write syscall and return its return value
}
static asmlinkage long ftrace_open(const struct pt_regs *reg) //open syscall hook
{
char __user *pathname = (char *)reg->di; //get third argument from pt_regs
strncpy_from_user(open_file, pathname, NAME_MAX); //string copy null byte aware
++open_count; //increase open count
return orig_open(reg); //call original open syscall and return its return value
}
static asmlinkage long ftrace_close(const struct pt_regs *reg) //close syscall hook
{
++close_count; //increase close count
return orig_close(reg); //call original close syscall and return its return value
}
static asmlinkage long ftrace_lseek(const struct pt_regs *reg) //lseek syscall hook
{
++lseek_count; //increase lseek count
return orig_lseek(reg); //call original lseek syscall and return its return value
}
/*
get read and write permission at address
*/
/*
void make_rw(void *addr)
{
unsigned int level;
pte_t *pte = lookup_address((u64)addr, &level); //get page table entry of address
if(pte->pte &~ _PAGE_RW) //if there is no write permission on the address
pte->pte |= _PAGE_RW; //turn on read write permission
}
*/
/*
retrieve read only permission at address
*/
/*
void make_ro(void *addr)
{
unsigned int level;
pte_t *pte = lookup_address((u64)addr, &level); //get page table entry of address
pte->pte = pte->pte &~ _PAGE_RW; //eliminate write permission
}
*/
static int __init hooking_init(void)
{
syscall_table = (void **)kallsyms_lookup_name("sys_call_table"); //get syscall table entry
//make_rw(syscall_table);
write_cr0(read_cr0() & (~0x10000)); //get page write permission
/*
store original syscalls
*/
orig_read = syscall_table[__NR_read];
orig_write = syscall_table[__NR_write];
orig_open = syscall_table[__NR_open];
orig_close = syscall_table[__NR_close];
orig_lseek = syscall_table[__NR_lseek];
/*
hook a user defined syscall
*/
syscall_table[__NR_read] = ftrace_read;
syscall_table[__NR_write] = ftrace_write;
syscall_table[__NR_open] = ftrace_open;
syscall_table[__NR_close] = ftrace_close;
syscall_table[__NR_lseek] = ftrace_lseek;
write_cr0(read_cr0() | 0x10000);
return 0;
}
static void __exit hooking_exit(void)
{
/*
restore pre-defined syscall
*/
write_cr0(read_cr0() & (~0x10000));
syscall_table[__NR_read] = orig_read;
syscall_table[__NR_write] = orig_write;
syscall_table[__NR_open] = orig_open;
syscall_table[__NR_close] = orig_close;
syscall_table[__NR_lseek] = orig_lseek;
write_cr0(read_cr0() | 0x10000);
//make_ro(syscall_table); //eliminate page write permission
}
module_init(hooking_init); //insert module
module_exit(hooking_exit); //exit module
can you guys give me an idea of how to solve this problem?
Segmentation violation detected on run
I'm new to MATLAB and I get the following crash information when running GISTIC2 based on MCR. No problem running that algorithm in other machine we are using. ------------------------------------------------------------------------ Segmentation violation detected at Thu Jul 8 23:01:05 2021 ------------------------------------------------------------------------ Configuration: Crash Decoding : Disabled Current Visual : 0x21 (class 4, depth 24) Default Encoding : UTF-8 GNU C Library : 2.31 stable MATLAB Architecture: glnxa64 MATLAB Root : /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83 MATLAB Version : 8.3.0.532 (R2014a) Operating System : Linux 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x86_64 Processor ID : x86 Family 143 Model 96 Stepping 1, AuthenticAMD Virtual Machine : Java 1.7.0_11-b21 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode Window System : The X.Org Foundation (12009000), display :0 Fault Count: 1 Abnormal termination: Segmentation violation Register State (from fault): RAX = 0000000000000000 RBX = 00007f7790b2c190 RCX = 0000000000000000 RDX = 0000000000000000 RSP = 00007f77f2becde8 RBP = 00007f77ec0376c0 RSI = 000000003e07c725 RDI = 0000000000000000 R8 = 0000000000000007 R9 = 00312d3634363031 R10 = 00007f77f2becc70 R11 = 0000000000000000 R12 = 0000000000000000 R13 = 00007f77f2bed180 R14 = 0000000000000000 R15 = 0000000000000000 RIP = 00007f7807063675 EFL = 0000000000010283 CS = 0033 FS = 0000 GS = 0000 Stack Trace (from fault): [ 0] 0x00007f7807063675 /lib/x86_64-linux-gnu/libc.so.6+01619573 [ 1] 0x00007f77f588ec18 /lib/x86_64-linux-gnu/libX11.so.6+00134168 XLoadQueryFont+00000056 [ 2] 0x00007f77f870adf0 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwuix.so+00261616 [ 3] 0x00007f77f870baae /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwuix.so+00264878 [ 4] 0x00007f77f870bd29 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwuix.so+00265513 [ 5] 0x00007f77f8e5d143 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwgui.so+00663875 _Z21wm_SetUnadjWindowFontP10WinRec_tagP6mxFont+00000083 [ 6] 0x00007f77f8e5d74b /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwgui.so+00665419 _Z22wm_GetDeviceFontExtentP10WinRec_tagP6mxFontPKcdP6mwrect+00000315 [ 7] 0x00007f77f8e78fff /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwgui.so+00778239 uiGetDeviceFont+00000815 [ 8] 0x00007f77f8e79171 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwgui.so+00778609 _Z15uiSetWindowFontP10WinRec_tagP6mxFont+00000017 [ 9] 0x00007f77f8e5d013 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwgui.so+00663571 _Z16wm_SetWindowFontP10WinRec_tagP6mxFont+00000083 [ 10] 0x00007f77a5d81195 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05001621 [ 11] 0x00007f77f8e9489d /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwgui.so+00891037 _ZN11gui_objects10tickpicker12nicefyLimitsERNS0_14AxisDescriptorENS0_8AxisTypeE+00000173 [ 12] 0x00007f77f8e94cc3 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwgui.so+00892099 _ZN11gui_objects10tickpicker12nicefyLimitsERNS0_14AxisDescriptorE+00000019 [ 13] 0x00007f77a5d816d9 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05002969 [ 14] 0x00007f77a5ce57df /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+04364255 [ 15] 0x00007f77a5cd0b1f /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+04279071 [ 16] 0x00007f77a5dd4740 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05343040 [ 17] 0x00007f77a5dd427c /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05341820 [ 18] 0x00007f77a5dc72b0 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05288624 [ 19] 0x00007f77f746bded /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwudd.so+00634349 [ 20] 0x00007f77f7465153 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwudd.so+00606547 _ZN11UDInterface15notifyPropEventEP16UDDatabaseClientPK10UDPropInfoPK11UDEventInfoP7UDEvent+00000115 [ 21] 0x00007f77f7468671 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwudd.so+00620145 _ZN11UDInterface4setEEP16UDDatabaseClientP10UDPropInfoPvP13UDErrorStatus+00000593 [ 22] 0x00007f77a5dd15b6 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05330358 [ 23] 0x00007f77a5dcbadd /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05307101 [ 24] 0x00007f77a5dca0d0 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05300432 [ 25] 0x00007f77a5db06f5 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05195509 [ 26] 0x00007f77a5dbdfd0 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05251024 [ 27] 0x00007f77a5db7408 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05223432 [ 28] 0x00007f77a5dbe432 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05252146 [ 29] 0x00007f77a5dc3113 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhg.so+05271827 hgSet+00001107 [ 30] 0x00007f77a6c80742 /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwhgbuiltins.so+00345922 ... [125] 0x00007f77fba703bf /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwmcr.so+00365503 [126] 0x00007f77fba6b28f /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/bin/glnxa64/libmwmcr.so+00344719 [127] 0x00007f78070d3609 /lib/x86_64-linux-gnu/libpthread.so.0+00038409 If this problem is reproducible, please submit a Service Request via: http://www.mathworks.com/support/contact_us/ A technical support engineer might contact you with further information. Thank you for your help.** This crash report has been saved to disk as /home/lcj/matlab_crash_dump.29508-1 ** Segmentation fault (core dumped) After renaming the libstdc++.so.6 library to libstdc++.so.6.old in ~/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83/sys/os/glnxa64, I got the following crash information. ------------------------------------------------------------------------ Segmentation violation detected at Sat Jul 10 23:22:39 2021 ------------------------------------------------------------------------ Configuration: Crash Decoding : Disabled Current Visual : 0x21 (class 4, depth 24) Default Encoding : UTF-8 GNU C Library : 2.31 stable MATLAB Architecture: glnxa64 MATLAB Root : /home/lcj/Biosoft/GISTIC2/MATLAB_Compiler_Runtime/v83 MATLAB Version : 8.3.0.532 (R2014a) Operating System : Linux 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x86_64 Processor ID : x86 Family 143 Model 96 Stepping 1, AuthenticAMD Virtual Machine : Java 1.7.0_11-b21 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode Window System : The X.Org Foundation (12009000), display :0 Fault Count: 1 Abnormal termination: Segmentation violation Register State (from fault): RAX = 0000000000000000 RBX = 00007f26c0b99880 RCX = 0000000000000000 RDX = 0000000000000000 RSP = 00007f2720dcede8 RBP = 00007f271c0376c0 RSI = 000000003e07c725 RDI = 0000000000000000 R8 = 0000000000000007 R9 = 00312d3634363031 R10 = 00007f2720dcec70 R11 = 0000000000000000 R12 = 0000000000000000 R13 = 00007f2720dcf180 R14 = 0000000000000000 R15 = 0000000000000000 RIP = 00007f2735246675 EFL = 0000000000010283 CS = 0033 FS = 0000 GS = 0000 Stack Trace (from fault): Caught "std::exception" Exception message is: FatalException Error:FatalException Any clues to solve this errors?
What are bsdthread_register, ulock_wake and other system calls reported by dtruss?
Here is an example interaction with dtruss on my macOS machine.
$ cat main.c
int main() {
return 0;
}
$ clang main.c
$ sudo dtruss ./a.out
dtrace: system integrity protection is on, some features will not be available
SYSCALL(args) = return
open("/dev/dtracehelper\0", 0x2, 0x7FFF5AF83930) = 3 0
ioctl(0x3, 0x80086804, 0x7FFF5AF838B8) = 0 0
close(0x3) = 0 0
thread_selfid(0x3, 0x80086804, 0x7FFF5AF838B8) = 5434813 0
bsdthread_register(0x7FFFAF245080, 0x7FFFAF245070, 0x2000) = 1073741919 0
ulock_wake(0x1, 0x7FFF5AF830EC, 0x0) = -1 Err#2
issetugid(0x1, 0x7FFF5AF830EC, 0x0) = 0 0
mprotect(0x104C7F000, 0x88, 0x1) = 0 0
mprotect(0x104C81000, 0x1000, 0x0) = 0 0
mprotect(0x104C97000, 0x1000, 0x0) = 0 0
mprotect(0x104C98000, 0x1000, 0x0) = 0 0
mprotect(0x104CAE000, 0x1000, 0x0) = 0 0
mprotect(0x104CAF000, 0x1000, 0x1) = 0 0
mprotect(0x104C7F000, 0x88, 0x3) = 0 0
mprotect(0x104C7F000, 0x88, 0x1) = 0 0
getpid(0x104C7F000, 0x88, 0x1) = 34522 0
stat64("/AppleInternal/XBS/.isChrooted\0", 0x7FFF5AF82FA8, 0x1) = -1 Err#2
stat64("/AppleInternal\0", 0x7FFF5AF83040, 0x1) = -1 Err#2
csops(0x86DA, 0x7, 0x7FFF5AF82AD0) = -1 Err#22
dtrace: error on enabled probe ID 2158 (ID 552: syscall::sysctl:return): invalid kernel access in action #10 at DIF offset 40
ulock_wake(0x1, 0x7FFF5AF83050, 0x0) = -1 Err#2
csops(0x86DA, 0x7, 0x7FFF5AF823B0) = -1 Err#22
Many of these system calls look familiar, but others don't. Specifically, what are thread_selfid, bsdthread_register, ulock_wake, csops, and dtrace? If these are system calls, they don't have man pages documenting them. Are they private system calls, or something else? Where does dtruss get their names from?
Yes, ULOCK_wake is part of a private systemcall for threads afaik. You can see it in the xnu sourcecode as being systemcall number 516.
ld linker script producing huge binary
I'm using binutils-2.21.53.0.1-6.fc16.x86_64.
I have a small object file, hello.o with just enough "stuff" to have contents in all sections:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000000 00000040
000000000000005d 0000000000000000 AX 0 0 4
[ 2] .rela.text RELA 0000000000000000 00000808
0000000000000060 0000000000000018 15 1 8
[ 3] .data PROGBITS 0000000000000000 000000a0
0000000000000000 0000000000000000 WA 0 0 4
[ 4] .bss NOBITS 0000000000000000 000000a0
0000000000000053 0000000000000000 WA 0 0 32
[ 5] .rodata PROGBITS 0000000000000000 000000a0
000000000000000f 0000000000000000 A 0 0 1
[ 6] .data.rel.local PROGBITS 0000000000000000 000000b0
0000000000000008 0000000000000000 WA 0 0 8
[ 7] .rela.data.rel.lo RELA 0000000000000000 00000868
0000000000000018 0000000000000018 15 6 8
[ 8] .data.rel PROGBITS 0000000000000000 000000b8
0000000000000008 0000000000000000 WA 0 0 8
[ 9] .rela.data.rel RELA 0000000000000000 00000880
0000000000000018 0000000000000018 15 8 8
[10] .comment PROGBITS 0000000000000000 000000c0
000000000000002d 0000000000000001 MS 0 0 1
[11] .note.GNU-stack PROGBITS 0000000000000000 000000ed
0000000000000000 0000000000000000 0 0 1
[12] .eh_frame PROGBITS 0000000000000000 000000f0
0000000000000058 0000000000000000 A 0 0 8
[13] .rela.eh_frame RELA 0000000000000000 00000898
0000000000000030 0000000000000018 15 12 8
[14] .shstrtab STRTAB 0000000000000000 00000148
0000000000000085 0000000000000000 0 0 1
[15] .symtab SYMTAB 0000000000000000 00000610
00000000000001b0 0000000000000018 16 11 8
[16] .strtab STRTAB 0000000000000000 000007c0
0000000000000045 0000000000000000 0 0 1
If I use -pie and no linker script, the results are as expected:
$ ld -pie -Map hello_pie.map -o hello_pie.elf hello.o
$ ll hello_pie.elf
-rwxrwx---. 1 jreinhart jreinhart 3453 Mar 13 23:44 hello_pie.elf
However, if I include any sort of linker script, the output size explodes:
$ cat 1.ld
SECTIONS
{
}
$ ld -T 1.ld -pie -Map hello_pie.map -o hello_pie.elf hello.o
$ ll hello_pie.elf
-rwxrwx---. 1 jreinhart jreinhart 2100070 Mar 13 23:45 hello_pie.elf
As you can see, this file became huge.
Note that this appears to happen because the .text section insists on starting at offset 0x200000 in the file:
$ readelf -l -S hello_pie.elf
There are 19 section headers, starting at offset 0x200400:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000000 00200000 <--- Why?
000000000000005d 0000000000000000 AX 0 0 4
[ 2] .rodata PROGBITS 000000000000005d 0020005d
000000000000000f 0000000000000000 A 0 0 1
[ 3] .eh_frame PROGBITS 0000000000000070 00200070
0000000000000058 0000000000000000 A 0 0 8
[ 4] .interp PROGBITS 00000000000000c8 002000c8
000000000000000f 0000000000000000 A 0 0 1
[ 5] .dynsym DYNSYM 00000000000000d8 002000d8
0000000000000078 0000000000000018 A 6 2 8
[ 6] .dynstr STRTAB 0000000000000150 00200150
0000000000000014 0000000000000000 A 0 0 1
[ 7] .hash HASH 0000000000000168 00200168
0000000000000028 0000000000000004 A 5 0 8
[ 8] .rela.dyn RELA 0000000000000190 00200190
0000000000000078 0000000000000018 A 5 0 8
[ 9] .data.rel.local PROGBITS 0000000000000208 00200208
0000000000000008 0000000000000000 WA 0 0 8
[10] .data.rel PROGBITS 0000000000000210 00200210
0000000000000008 0000000000000000 WA 0 0 8
[11] .dynamic DYNAMIC 0000000000000218 00200218
00000000000000f0 0000000000000010 WA 6 0 8
[12] .got PROGBITS 0000000000000308 00200308
0000000000000018 0000000000000008 WA 0 0 8
[13] .got.plt PROGBITS 0000000000000320 00200320
0000000000000018 0000000000000008 WA 0 0 8
[14] .bss NOBITS 0000000000000340 00200338
0000000000000053 0000000000000000 WA 0 0 32
[15] .comment PROGBITS 0000000000000000 00200338
000000000000002c 0000000000000001 MS 0 0 1
[16] .shstrtab STRTAB 0000000000000000 00200364
000000000000009a 0000000000000000 0 0 1
[17] .symtab SYMTAB 0000000000000000 002008c0
0000000000000258 0000000000000018 18 19 8
[18] .strtab STRTAB 0000000000000000 00200b18
000000000000004e 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000200040 0x0000000000000000
0x0000000000000118 0x0000000000000118 R E 8
INTERP 0x00000000002000c8 0x00000000000000c8 0x00000000000000c8
0x000000000000000f 0x000000000000000f R 1
[Requesting program interpreter: /lib/ld64.so.1]
LOAD --> 0x0000000000200000 0x0000000000000000 0x0000000000000000
0x0000000000000338 0x0000000000000393 RWE 200000
DYNAMIC 0x0000000000200218 0x0000000000000218 0x0000000000000218
0x00000000000000f0 0x00000000000000f0 RW 8
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 8
This has been happening regardless of the contents of my linker script. Any ideas what's going on?
I ran into this same problem today when learning about linker scripts. SIZEOF_HEADERS was the magic bullet to solve it. Here is my simple source file to build the object I'm linking:
.section .text
.global _start
_start:
mov $1, %eax
mov $8, %ebx
int $0x80
With the following linker script, I get a 2+ MB executable:
SECTIONS
{
. = 0x400000;
.text : { *(.text) }
}
If I add +SIZEOF_HEADERS, as shown below, I get a 568-byte executable:
SECTIONS
{
. = 0x400000 + SIZEOF_HEADERS;
.text : { *(.text) }
}
Per the LD documentation, this function returns the size of the output file's headers. Manually setting the offset to include the header size also yields a 568-byte executable:
SECTIONS
{
. = 0x400078;
.text : { *(.text) }
}
If I move .text even further down, the executable starts to expand. The following yields a 65984-byte executable:
SECTIONS
{
. = 0x410000;
.text : { *(.text) }
}
So basically, from what I can tell, it appears that:
The first output section appears to share a memory page with the output file headers. If the first section overlaps with the headers, LD emits a full page of pad bytes before outputting the first section to avoid a conflict
To fix this, set the output address for the first output section to X + SIZEOF_HEADERS. This is what the built-in linker script for LD does (you can take a look by running "ld --verbose")
Try the following command line option with ld (or gcc): -z max-page-size=0x1000
By default ld page-aligns input sections. Since your kernel enforces superpages (pages of 2MB = 0x200000 bytes) your .text section gets aligned at offset 0x200000. It seems like a bug in ld as it should use offset 0x0000000 instead (see EDIT below for a possible explanation) To prevent this alignment which creates a bigger file, you can use the --nmagic flag to ld to prevent it from page-aligning your .text section although it has side effects (it also disables linking against shared libraries). Be careful though to align other sections (.data, .rodata,...) to 2M pages because they can't live in the same page as .text since all these sections require different access bits. EDIT: thinking about it, we all expect accesses to virtual address 0x00000000 to generate an exception (segfault). To do so, I see two possibilities: either the kernel maps a page with no access rights (r/w/x) or (more likely) it simply doesn't map anything (no page mapped => segfault) and the linker must know that somehow... that could explain why ld skips the first page which is at address zero. This is TBC.
app not running after enabling gcUnmanagedToManaged MDA
Because of heap corruption I enabled gcUnmanagedToManaged MDA through a system environment variable. Unfortunately I can't run my app anymore. I always get something like the following: (a78.1150): Unknown exception - code e053534f (first chance) eax=00000000 ebx=00dff8ac ecx=00000000 edx=00000000 esi=00000003 edi=00000000 eip=7779013d esp=00dff85c ebp=00dff8f8 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 ntdll!NtWaitForMultipleObjects+0x15: 7779013d 83c404 add esp,4 All my threads seem to be killed (XXXX): 0:002> !threads ThreadCount: 5 UnstartedThread: 1 BackgroundThread: 3 PendingThread: 0 DeadThread: 0 Hosted Runtime: no PreEmptive GC Alloc Lock ID OSID ThreadOBJ State GC Context Domain Count APT Exception XXXX 1 c98 00401568 6020 Enabled 00000000:00000000 003c7698 4 STA XXXX 2 4cc 0040be80 b220 Enabled 00000000:00000000 003c7698 0 MTA (Finalizer) XXXX 3 1150 05525948 7220 Disabled 00000000:00000000 003c7698 0 STA System.StackOverflowException (0265106c) XXXX 4 e2c 055778c0 200b220 Enabled 00000000:00000000 003c7698 1 MTA XXXX 5 0 055b4a28 1600 Enabled 00000000:00000000 003c7698 0 Ukn As soon as I get rid of COMPLUS_MDA=gcUnmanagedToManaged it's working as expected. My system is x86 with .net 3.5 SP1. Any hints? UPDATE: I also tried to debug it: 0:002> k 0xffff ChildEBP RetAddr 00eef8cc 757015e9 ntdll!NtWaitForMultipleObjects+0x15 00eef968 75091a2c KERNELBASE!WaitForMultipleObjectsEx+0x100 00eef9b0 75094220 KERNEL32!WaitForMultipleObjectsExImplementation+0xe0 00eef9cc 724a7821 KERNEL32!WaitForMultipleObjects+0x18 00eefa2c 724a777e mscorwks!DebuggerRCThread::MainLoop+0xe9 00eefa5c 724a76a5 mscorwks!DebuggerRCThread::ThreadProc+0xe5 00eefa8c 750933aa mscorwks!DebuggerRCThread::ThreadProcStatic+0x9c 00eefa98 777a9ef2 KERNEL32!BaseThreadInitThunk+0xe 00eefad8 777a9ec5 ntdll!__RtlUserThreadStart+0x70 00eefaf0 00000000 ntdll!_RtlUserThreadStart+0x1b