Re: [classlib][launcher] should we get rid of one of the HyPortLibrary function tables in DRLVM?

2006-10-04 Thread Evgueni Brevnov
Hi, I see the same. I looked at the problem closer. It turned out to be the problem of Microsoft debugger. Seems like debug information is damaged somehow. What I did? I set breakpoint at line 290 of modules\luni\src\main\native\launcher\shared\main.c. Printed out args-portLibrary. It is valid

Re: [classlib][launcher] should we get rid of one of the HyPortLibrary function tables in DRLVM?

2006-10-04 Thread Weldon Washburn
On 10/4/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, I see the same. I looked at the problem closer. It turned out to be the problem of Microsoft debugger. Seems like debug information is damaged somehow. What I did? I set breakpoint at line 290 of

[classlib][launcher] should we get rid of one of the HyPortLibrary function tables in DRLVM?

2006-10-01 Thread Weldon Washburn
All, Using windows debugger, I see native/launcher/shared/main.c::invocation() receive an incoming argument that looks to be a DRLVM version of HyPortLibrary with all the functions zeroed out. Does anyone else see this?? Passing a HyPortLibrary with the function ptrs nulled out is not the