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 structure at that moment. Make one step over the line 290. Ups ... args->portLibrary become invalid but line number 290 looks like if(newPathToAdd == NULL). So it can't crash portLibrary. I played a little with commenting out the code and got the same problem in different places. That's why I think this is debugger problem.
Thanks Evgueni On 10/2/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
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 primary concern. At worst, this will cause a sigsegv and should be straight forward to debug. The big concern is accidentally using the classlib/HyPortLibrary function ptr table when DRLVM Threading Manager APIs are intended. This could cause all sorts of strange deadlocks. I have looked at the code to prove or disprove that the two HyPortLibraries are being confused. So far, no luck. There are too many layers to get to the bottom of this quickly. Does anyone know the answer to the above question? If not, should I open a JIRA on this issue? -- Weldon Washburn Intel Middleware Products Division
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
