Bug 775 (http://www.reactos.com/bugzilla/show_bug.cgi?id=775) seems to be a
simple application bug. I expect no kernel involvement at all. So, if you
were always wanting to fix something in ReactOS but were afraid it might be
too complicated, this bug is for you. It should give you experience in
building and debugging ReactOS so maybe next time you can attack something a
little bit more complicated.
Gé van Geldorp.
hbirr(a)svn.reactos.com wrote:
>Fixed the MP build.
>
Hi Hartmut,
I'm really sorry, I forgot to test MP=1 :(
We really need a way to ensure that KDBG/MP code always gets built... it
would cause less problems...
Best regards,
Alex Ionescu
I'm working on bug 713 (http://www.reactos.com/bugzilla/show_bug.cgi?id=713
for the click-happy). What I have found is this:
- Telnet opens a socket
- Sending and receiving are handled by different threads, let's call them S
and R
- Thread R starts a recv() operation, which is translated to an ioctl on the
socket
- No data is available, so thread R blocks, waiting for FileObject->Event
- I type something, which is handled by thread S. Thread S starts a send()
operation.
- Again translated to an ioctl on the socket. Since this is the same socket
as used by S, the FileObject will be the same
- The send can complete immediately, IoCompleteRequest is called which sets
the FileObject->Event.
- Thread R is unblocked, the event it was waiting for was set by thread S.
However, the irp of thread R was never completed. The recv() call returns
with bogus info.
- Thread R starts another recv(). When some data arrives from the server,
two irps are waiting for it. This eventually leads to the crash.
The fundamental problem seems to be multiple overlapping I/O operations
which all use FileObject->Event to signal their completion. I have no idea
how to fix that...
Gé van Geldorp.
I'm sorry if this would a wrong place to post this, but since I'm
trying the ReactOS uxtheme.dll, I figured this would be fine.
I've compiled today's SVN, and I noticed that ReactOS had a
uxtheme.dll (didn't know that before :P). Well, as a try, I went and
put it on a Windows XP Professional machine (no service pack, and the
Microsoft uxtheme.dll is un-patched). When I rebooted with the ReactOS
DLL, Windows XP freezes at the welcome screen, the start up sound
doesn't even play.
So I'm wondering if uxtheme.dll isn't complete yet or if it's already
known to have problems.
--
Mike
Few questions about freeldr
- Is there a compelling reason to have pointer members
of LOADER_PARAMETER_BLOCK such as ModsAddr
as ULONGs ? (include/ndk/haltypes.h)
- Why the kernel module (ntoskrnl.exe) in not treated as such
in the loader (there is a special case to create the corresponding
module object in the kernel) ?
- Why MachGetMemoryMap() is called twice:
in freeldr/mm/meminit.c and in freeldr/reactos/reactos.c ?
- wouldn't it be nicer to fix these ?
Hi All!
Files on reactos/lib/msafd/misc/ uses header "msafd.h" from
reactos/lib/msafd/. On my system, MinGW/linux successfully compiled
these files ONLY after I manually corrected include directive:
#include <../msafd.h>
instead
#include <msafd.h>
in all 5 *.c files in reactos/lib/msafd/misc/.
Maybe we must make this replacement in svn tree? Or it was my
misconfiguration? ;)
WBR,
DarkHobbit