Hello!
Time flies fast, and soon we are going to face the deadline (next status meeting) by which we decided to create a RC of the upcoming release. And, there are some problems.
I will start from good stuff. Since the last meeting took place, quite a few regressions were fixed, and interesting bugs have also been closed. This is very good and I appreciate your efforts.
However some problems remains, and here is where your help is urgently needed! For the current milestone (0.3.14), there are 3 blocker regressions and 2 big buckets of issues - ldr rewrite regressions and shell32 rewrite regressions.
From blocker stuff, the most important is the heap-related one. Mephisto provided a good explanation here (http://www.reactos.org/bugzilla/show_bug.cgi?id=5857), and we need someone with a fresh eye to look into this problem. N.B. Please don't go into "let's fix some unrelated stuff in the heap code just to make it better". Look strictly into the specified bug and try to spot the place where the heap lists are getting corrupted. Anyone volunteers to have a look?
LDR regressions: there are relatively many of them, but all are more-or-less nicely fixable because of the new, good LDR code. Alex - maybe you could please devote a bit of your time to check the code and see if that fixes some of the regressions?
shell32 regressions: I already see some improvements being committed, please continue this way.
We can make a good 0.3.14 release only if we act as a team now. It's not someone, it's YOUR help which matters. Testers are already doing as much as they can, retesting issues, providing newer debug logs, and other other things. Now it's time to act and fix regressions before moving further. It's just stupid to move further, if a rewrite introduces new bugs instead of fixing existing. I know how hard it is, but let's finish smaller steps and hence move forward.
There is no way forward at all if old bugs are stacked and new regressions are introduced all the time. We can't bring in new good changes (wine syncs, 3rd party code syncs, arwinss, whatever else) until 0.3.14 is ready, and 0.3.14 is not ready until blocking regressions are fixed. As simple as it is.
Thanks for reading and I hope you understand.
With the best regards, Aleksey Bragin.
Another blocker is the CMake backtrace problems reported by Caemyr if their still not fixed.
Btw what will be the RC release of ROS, CMake or RBuild?
Quote: 1. the whole process takes minutes more per frame: you need the base address, add the offset and type in the addr2line command 2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line doesn't know about that... 3. C++ function names are not demangled. For those modules that are written in c++ you will only get source lines, unless you check them up manually. 4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a backtrace... on the other hand, do you expect anyone to waste half an hour doing so?
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: Friday, 21 October 2011 5:41 AM To: ros-dev@reactos.org Subject: [ros-dev] Regressions / release status
Hello!
Time flies fast, and soon we are going to face the deadline (next status meeting) by which we decided to create a RC of the upcoming release. And, there are some problems.
I will start from good stuff. Since the last meeting took place, quite a few regressions were fixed, and interesting bugs have also been closed. This is very good and I appreciate your efforts.
However some problems remains, and here is where your help is urgently needed! For the current milestone (0.3.14), there are 3 blocker regressions and 2 big buckets of issues - ldr rewrite regressions and shell32 rewrite regressions.
From blocker stuff, the most important is the heap-related one. Mephisto provided a good explanation here (http://www.reactos.org/bugzilla/show_bug.cgi?id=5857), and we need someone with a fresh eye to look into this problem. N.B. Please don't go into "let's fix some unrelated stuff in the heap code just to make it better". Look strictly into the specified bug and try to spot the place where the heap lists are getting corrupted. Anyone volunteers to have a look?
LDR regressions: there are relatively many of them, but all are more-or-less nicely fixable because of the new, good LDR code. Alex - maybe you could please devote a bit of your time to check the code and see if that fixes some of the regressions?
shell32 regressions: I already see some improvements being committed, please continue this way.
We can make a good 0.3.14 release only if we act as a team now. It's not someone, it's YOUR help which matters. Testers are already doing as much as they can, retesting issues, providing newer debug logs, and other other things. Now it's time to act and fix regressions before moving further. It's just stupid to move further, if a rewrite introduces new bugs instead of fixing existing. I know how hard it is, but let's finish smaller steps and hence move forward.
There is no way forward at all if old bugs are stacked and new regressions are introduced all the time. We can't bring in new good changes (wine syncs, 3rd party code syncs, arwinss, whatever else) until 0.3.14 is ready, and 0.3.14 is not ready until blocking regressions are fixed. As simple as it is.
Thanks for reading and I hope you understand.
With the best regards, Aleksey Bragin.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
These will all be non-issues with the new RosBE.
It was basically user error. Users did not know how to use addr2line, plus the version in RosBE is broken. The new RosBE will have a working version, plus a script to make it easier for users so they don't have to read a help file to learn how to use the tool.
-- Best regards, Alex Ionescu
On 2011-10-20, at 3:03 PM, dmex wrote:
Another blocker is the CMake backtrace problems reported by Caemyr if their still not fixed.
Btw what will be the RC release of ROS, CMake or RBuild?
Quote:
- the whole process takes minutes more per frame: you need the base
address, add the offset and type in the addr2line command 2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line doesn't know about that... 3. C++ function names are not demangled. For those modules that are written in c++ you will only get source lines, unless you check them up manually. 4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a backtrace... on the other hand, do you expect anyone to waste half an hour doing so?
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Aleksey Bragin Sent: Friday, 21 October 2011 5:41 AM To: ros-dev@reactos.org Subject: [ros-dev] Regressions / release status
Hello!
Time flies fast, and soon we are going to face the deadline (next status meeting) by which we decided to create a RC of the upcoming release. And, there are some problems.
I will start from good stuff. Since the last meeting took place, quite a few regressions were fixed, and interesting bugs have also been closed. This is very good and I appreciate your efforts.
However some problems remains, and here is where your help is urgently needed! For the current milestone (0.3.14), there are 3 blocker regressions and 2 big buckets of issues - ldr rewrite regressions and shell32 rewrite regressions.
From blocker stuff, the most important is the heap-related one. Mephisto provided a good explanation here (http://www.reactos.org/bugzilla/show_bug.cgi?id=5857), and we need someone with a fresh eye to look into this problem. N.B. Please don't go into "let's fix some unrelated stuff in the heap code just to make it better". Look strictly into the specified bug and try to spot the place where the heap lists are getting corrupted. Anyone volunteers to have a look?
LDR regressions: there are relatively many of them, but all are more-or-less nicely fixable because of the new, good LDR code. Alex - maybe you could please devote a bit of your time to check the code and see if that fixes some of the regressions?
shell32 regressions: I already see some improvements being committed, please continue this way.
We can make a good 0.3.14 release only if we act as a team now. It's not someone, it's YOUR help which matters. Testers are already doing as much as they can, retesting issues, providing newer debug logs, and other other things. Now it's time to act and fix regressions before moving further. It's just stupid to move further, if a rewrite introduces new bugs instead of fixing existing. I know how hard it is, but let's finish smaller steps and hence move forward.
There is no way forward at all if old bugs are stacked and new regressions are introduced all the time. We can't bring in new good changes (wine syncs, 3rd party code syncs, arwinss, whatever else) until 0.3.14 is ready, and 0.3.14 is not ready until blocking regressions are fixed. As simple as it is.
Thanks for reading and I hope you understand.
With the best regards, Aleksey Bragin.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi! I just fixed the new error log spam, setting the fnId death bit before WM_NCDESTROY was sent. Once this is in, the rest can wait. This was in an effort to fix Jre before the release. Realizing ReactOS has inherited a bad message system from wine.
AbiWord will not load correctly due to vcredist, ldr issue? It looks as if it is relocating and then stops, calls it good and seems to install faster than it should.
Bug 5560 has a partial wine sync of Ole32, only for Ole2, I've tested it. I would like someone to look at it. I know this is marked 0.4.0 bug, but I think it should go in.
Bug 5857 has a test patch, did it work?
Bug 5884 never seen it happen over here....
More bugs to smash! James
On Thu, Oct 20, 2011 at 4:41 PM, Aleksey Bragin aleksey@reactos.org wrote:
Hello!
Time flies fast, and soon we are going to face the deadline (next status meeting) by which we decided to create a RC of the upcoming release. And, there are some problems.
I will start from good stuff. Since the last meeting took place, quite a few regressions were fixed, and interesting bugs have also been closed. This is very good and I appreciate your efforts.
However some problems remains, and here is where your help is urgently needed! For the current milestone (0.3.14), there are 3 blocker regressions and 2 big buckets of issues - ldr rewrite regressions and shell32 rewrite regressions.
From blocker stuff, the most important is the heap-related one. Mephisto provided a good explanation here (http://www.reactos.org/bugzilla/show_bug.cgi?id=5857), and we need someone with a fresh eye to look into this problem. N.B. Please don't go into "let's fix some unrelated stuff in the heap code just to make it better". Look strictly into the specified bug and try to spot the place where the heap lists are getting corrupted. Anyone volunteers to have a look?
LDR regressions: there are relatively many of them, but all are more-or-less nicely fixable because of the new, good LDR code. Alex - maybe you could please devote a bit of your time to check the code and see if that fixes some of the regressions?
shell32 regressions: I already see some improvements being committed, please continue this way.
We can make a good 0.3.14 release only if we act as a team now. It's not someone, it's YOUR help which matters. Testers are already doing as much as they can, retesting issues, providing newer debug logs, and other other things. Now it's time to act and fix regressions before moving further. It's just stupid to move further, if a rewrite introduces new bugs instead of fixing existing. I know how hard it is, but let's finish smaller steps and hence move forward.
There is no way forward at all if old bugs are stacked and new regressions are introduced all the time. We can't bring in new good changes (wine syncs, 3rd party code syncs, arwinss, whatever else) until 0.3.14 is ready, and 0.3.14 is not ready until blocking regressions are fixed. As simple as it is.
Thanks for reading and I hope you understand.
With the best regards, Aleksey Bragin.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Aleksey Bragin -
Alex Ionescu -
dmex -
James Tabor