7.4.28 have a problem with Win32 and multiple processors. I'm going to try (again) to make a binary search for when the problem was introduced, but if someone has any ideas feel free to share. This is where it breaks when trying to run the installer:
What exactly is it it fails on? You could expand SWAP_IN_THREAD_IF_REQUIRED to all its components. How many threads are there? Which holds the interpreter lock?
fmt looks messed up but maybe it's the debugger that doesn't handle varargs correctly.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 16:57: Subject: Win32 SMP
7.4.28 have a problem with Win32 and multiple processors. I'm going to try (again) to make a binary search for when the problem was introduced, but if someone has any ideas feel free to share. This is where it breaks when trying to run the installer:
http://peter.bortas.org/pikedev/smpcrash.JPG
/ Peter Bortas
I could? How do you expand a macro in VC++s debugger?
How do I know how many threads are running and which holds the lock?
/ Peter Bortas
Previous text:
2003-09-20 17:04: Subject: Win32 SMP
What exactly is it it fails on? You could expand SWAP_IN_THREAD_IF_REQUIRED to all its components. How many threads are there? Which holds the interpreter lock?
fmt looks messed up but maybe it's the debugger that doesn't handle varargs correctly.
/ Martin Stjernholm, Roxen IS
Btw, have you compiled with --with-rtldebug? If not, that's the first thing to do.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 17:16: Subject: Win32 SMP
I could? How do you expand a macro in VC++s debugger?
How do I know how many threads are running and which holds the lock?
/ Peter Bortas
You'd have to expand it either by hand or by using gcc -E, insert lots of line breaks and then recompile.
I know nothing of how the VC++ debugger works, but there got to be some way of switching to another thread to examine its stack. As for the lock, you could either call gdb_backtraces if it's possible to do that, or else you have to look at the swapped flag in the thread structs. gdb_next_thread_state in threads.c shows how to go through them.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 17:16: Subject: Win32 SMP
I could? How do you expand a macro in VC++s debugger?
How do I know how many threads are running and which holds the lock?
/ Peter Bortas
Well, there is that threadview shown in the screenshot, and that one only shows one thread. Other than that I can't find anything. There is a "Step in to specific function" in the debug menu, but it's greyed out.
/ Peter Bortas
Previous text:
2003-09-20 17:22: Subject: Win32 SMP
You'd have to expand it either by hand or by using gcc -E, insert lots of line breaks and then recompile.
I know nothing of how the VC++ debugger works, but there got to be some way of switching to another thread to examine its stack. As for the lock, you could either call gdb_backtraces if it's possible to do that, or else you have to look at the swapped flag in the thread structs. gdb_next_thread_state in threads.c shows how to go through them.
/ Martin Stjernholm, Roxen IS
Ok, so it's probably not a multithread problem then. That should simplify the bug hunt a lot.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 17:39: Subject: Win32 SMP
Well, there is that threadview shown in the screenshot, and that one only shows one thread. Other than that I can't find anything. There is a "Step in to specific function" in the debug menu, but it's greyed out.
/ Peter Bortas
*kicks on VC++ for beeing unable to produce a proper backtrace*
Basicly:
va_error Pike_error Backend_event_handler call_c_initalizers debug_clone_object init_backend low_init_main init_modules main
/ Peter Bortas
Previous text:
2003-09-20 16:57: Subject: Win32 SMP
7.4.28 have a problem with Win32 and multiple processors. I'm going to try (again) to make a binary search for when the problem was introduced, but if someone has any ideas feel free to share. This is where it breaks when trying to run the installer:
http://peter.bortas.org/pikedev/smpcrash.JPG
/ Peter Bortas
Open the call stack window.
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 17:07: Subject: Win32 SMP
*kicks on VC++ for beeing unable to produce a proper backtrace*
Basicly:
va_error Pike_error Backend_event_handler call_c_initalizers debug_clone_object init_backend low_init_main init_modules main
/ Peter Bortas
There we go
va_error(const char * 0x00447f8f, char * 0x0054216c) line 196 + 19 bytes Pike_error(const char * 0x0054216c) line 360 + 14 bytes Backend_event_handler(int 0) line 2041 + 278 bytes call_c_initializers(object * 0x004716dd) line 245 + 3 bytes debug_clone_object(program * 0x014a536c, int 0) line 311 init_backend() line 2146 low_init_main() line 815 init_modules() line 70 main(int 11, char * * 0x01300de0) line 701 PIKE! mainCRTStartup + 197 bytes KERNEL32! 77e814c7()
/ Peter Bortas
Previous text:
2003-09-20 17:12: Subject: Win32 SMP
Open the call stack window.
/ Martin Nilsson (saturator)
I wonder how to interpret the +x bytes if the line is a macro.
You can see the threads by chosing Threads... in the Debug menu BTW.
/ Martin Nilsson (saturator)
Previous text:
2003-09-20 17:19: Subject: Win32 SMP
There we go
va_error(const char * 0x00447f8f, char * 0x0054216c) line 196 + 19 bytes Pike_error(const char * 0x0054216c) line 360 + 14 bytes Backend_event_handler(int 0) line 2041 + 278 bytes call_c_initializers(object * 0x004716dd) line 245 + 3 bytes debug_clone_object(program * 0x014a536c, int 0) line 311 init_backend() line 2146 low_init_main() line 815 init_modules() line 70 main(int 11, char * * 0x01300de0) line 701 PIKE! mainCRTStartup + 197 bytes KERNEL32! 77e814c7()
/ Peter Bortas
It's probably the number of bytes from the first machine instruction associated with that line. I don't think debugger cares that it's a macro.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-20 17:34: Subject: Win32 SMP
I wonder how to interpret the +x bytes if the line is a macro.
You can see the threads by chosing Threads... in the Debug menu BTW.
/ Martin Nilsson (saturator)
pike-devel@lists.lysator.liu.se