Regressions / release status

[Aleksey Bragin]

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.

[dmex]

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(a)reactos.org [mailto:[e-mail]] On
Behalf Of Aleksey Bragin
Sent: Friday, 21 October 2011 5:41 AM
To: ros-dev(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

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:
>  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(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Aleksey Bragin
>  Sent: Friday, 21 October 2011 5:41 AM
>  To: ros-dev(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[James Tabor]

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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>