Filed as #6753.
MinGW / Msys-1.0: Sh.exe deadlock seems to be result of unhandled
exception.
(I.e. got nothing to do with batch processing).
Best Regards
// Love
It may be old news, but the fact that RtlSetUnhandledExceptionFilter is
unimplemented
makes it impossible for many apps to handle their heap allocation
errors, aggravating
the work for the memory manager, and resulting in crashes, leaks, and
heap corruption.
Whoever knows our SEH well enough could do a major improvement by fixing
this.
I came across this while testing MinGW 20100909 on r 54606,
where sh.exe deadlocks after causing leaks in base/shell/cmd/batch.c
[213,116,332].
(I was aiming for a fully bootstrapped system by letting ROS build ROS.)
I'll try to establish a trace on the batch processing bug, and file it.
Best Regards
// Love
I've come across a whopper size bug, likely somewhere in USER or GDI (in
r54606).
If you switch app while you have a modal dialog open, and the new window
covers that dialog,
then when you come back that dialog is invisible, but it's window proc
still active, meaning
you have no way to back out of it, and you have to kill the app with
taskman (if you can).
I would nominate this a real blocker, it's just too embarrassing to release.
I'll try to figure a repeatability and file a bug, and I'd recommend
that USER and GDI
devs heed Alekseys request for feature freeze and roll up their sleeves
on this one.
Best Regards
// Love
Hello testers,
your help is greatly needed.
Trunk needs to be tested using this template as a guideline
http://www.reactos.org/wiki/Tests_for_0.3.14
Imagine that trunk is a 0.3.14 RC (I don't want to branch because I
already called for a feature freeze, so essentially trunk is in "release
mode" right now, and branching would just require merging all revisions
from trunk to the branch).
Fill in the revision number in the "comments" section of that page when
you test.
Also, please be prepared that this might be a double work because after
testing more changes (fixes) would come in and eventually require
retesting, but it is vital to get clear non-biased understanding on how
well trunk performs right now.
Thank you,
looking forward to see results,
Aleksey Bragin.
Quick typo, your param checks in LdrpCheckForKnownDll come after your initialization
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org
Sent: 07 December 2011 17:51
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [fireball] 54606: [NTDLL/LDR] - Improve LdrpCheckForKnownDll by adding parameters validation, return status value, better failure paths handling.
Author: fireball
Date: Wed Dec 7 17:51:18 2011
New Revision: 54606
URL: http://svn.reactos.org/svn/reactos?rev=54606&view=rev
Log:
[NTDLL/LDR]
- Improve LdrpCheckForKnownDll by adding parameters validation, return status value, better failure paths handling.
Modified:
trunk/reactos/dll/ntdll/include/ntdllp.h
trunk/reactos/dll/ntdll/ldr/ldrutils.c
Olaf, please don't leave, the project needs you just
as much as it needs the developers.
Eric, Olaf's regression testing can not entail patching/rebuilding
the system to accomodate disk structure (as you surely realize).
That said, your reasons for change are sound, but perhaps you
can make provisions to temporarily revert this if it causes massive
problems. The timing _is_ not good if indeed a release is close
at hand.. Can it wait until after the release?
Alex, calling Olaf "not an OS tester" is a bit harsh, don't you think?
Not everyone can be as weather hardened and experienced as you are.
Regarding the reasons for change:
Max CHS capacity: 10 bit C, 6 bit S, 8 bit H
2^10 * 2^6 * 255 == 16711680 sect(512) == 8.5 GB
This is the geometry Eric wants to use, which makes sense
because it can utilize the full CHS addressing capacity,
and reflects the absolute limit of BIOS int 13h CHS calls.
Previous 32S 64H CHS limit:
2^10 * 32 * 64 == 2097152 sect(512) == 1 GB
This is an artificial and unnecessary limit, imposed by some
strange design decision in Redmond a long long time ago.
For non-devs: In CHS mode BIOS has an absolute disk limit of 8.5 GB,
due to the available address bits, a 10/6 bit Cylinder/Sector composite,
and an 8 bit head number. Any disk bigger than that can only be addressed
in LBA mode (logical sector nr), which has a limit of 2^32 sectors == 2 TB.
And, if anyone didn't know, the geometry parameters are stored
in the boot sector, not in the MBR.
There's more to it, but I stop at that.
So.. Eric's change _should_ not cause any problem on disks
larger than 8.5 GB, since they run in LBA mode by necessity.
Concordingly, there could be forseeable problems on virtual disks
which will often be smaller than 8 GB and may be running CHS mode.
That'll be my penny to the pot for now.
PS. A standard sector is 512 bytes. Bigger sectors, e.g 1kB, have been used
in the past to increase capacity, but are _very_ unusual since they require
proportionately higher bit frequencies on the media and are error-prone.
Best Regards
// Love
This should fix a bunch of weird issues with 3rd party NIC drivers. Most NICs use deserialized drivers and indicate packets using the NdisMIndicatePacket function. I'm fairly sure every modern NIC driver will display a similar problem to http://www.reactos.org/paste/index.php/9607/ and http://www.reactos.org/paste/index.php/9608/ where the driver eventually depletes its packet pool then quits sending and receiving packets. It also causes a leak of non-paged pool since we leak the buffers attached to the packet descriptor. The VirtIO NetKVM driver seems to have a particularly small packet queue (256 RX) and dies very early.
I'd be interested to see what kind of uptime you guys can get with a 3rd party NIC driver now. I'm going to do some testing here in VirtualBox with a PRO/1000 to see how much data I can send/receive without problems.
Regards,
Cameron
Hello,
Let me invite you to the monthly status meeting taking place last thursday
of this month, 24th of November, 19:00 UTC.
The meeting will be atirc://fezile.reactos.org (Port 6667, no SSL) in the
channel #meeting. Note that the IRC service will only be started shortly
before the meeting. Everyone is invited to listen, and active community
members have their passwords so that they can participate in the
discussion.
If someone still is not getting passwords sent before a meeting - please
email
Colin or Pierre before the meeting started to get one.
Proposed agenda for the meeting:
1. Release status
2. Website revamp status
3. CMake adoption status
More suggestions are welcome as usual.
With the best regards,
Aleksey Bragin.
