ROS not loading in virtuel pc2004sp1 or beta virtuel pc 2007
Moderator: Moderator Team
ROS not loading in virtuel pc2004sp1 or beta virtuel pc 2007
I have upadted and recomplied the boot cd but it wont get passed the ros boot screen after copying the files to the hdd.
Any ideas why?
Any ideas why?
-
- Posts: 134
- Joined: Thu Jan 13, 2005 9:11 pm
- Location: Pordenone, Italy
-
- Posts: 107
- Joined: Fri Sep 08, 2006 2:56 pm
-
- Posts: 134
- Joined: Thu Jan 13, 2005 9:11 pm
- Location: Pordenone, Italy
I install the OS in a empty machine on virtual PC (or qemu, the problem seems to be the same), after install the system reboots ad prompts for OS selection (ROS or ROS debug). If i select ROS the system seems to hang on the boot splash and doesn't give any error. if i select ROS debug the system seems to hang after loading of csrss (it writes Client/Server Run-Time (Build 20070103-r25283) and then locks..). At this point VPC takes a lot of CPU (approx 50% on a P4 2.8GHz with HT). I compiled ros by myself using the latest sources available on the trunk today...
See this thread (amongst others) - I get a kernel loop in ntoskrnl.exe
http://www.reactos.org/forum/viewtopic. ... 5258#25258
This is a known problem being worked on - tried todays SVN ISO and still same
http://www.reactos.org/forum/viewtopic. ... 5258#25258
This is a known problem being worked on - tried todays SVN ISO and still same
hto wrote:Bug report: http://www.reactos.org/bugzilla/show_bug.cgi?id=1943
Code: Select all
NtOpenKey() calls ObpCaptureObjectAttributes() which can return null
ObjectName.
Then null pointer used in
if (ObjectName.Buffer[(ObjectName.Length / sizeof(WCHAR)) - 1] == '\\')
which leads to crash.
The code looks a bit unsafe. Can't comment fully as I can't see the preconditions but it has the potential to divide zero .length (0/n) overflow.
Empty/unassigned objs are a pain - I tend to always check for null pointers before trying to dereference. I'ts cut down bugs in my own code quite a bit and the checks are fairly trivial. Either that or perhaps some assertions until the code is finished?
I use a strempty() macro before using ptrs although I accept that its good to keep code as simple as possible in time-critical kernel loops and prove the code mathematically instead.
#define strempty(str) (str!=NULL ? (str[0]=='\0') : TRUE)
//C Pseudocode
if(!strempty(obj.whatever))
{
do { something_safely(obj.whatever) };
}
else
{
fprintf(stderr,"Oops!, bug!\n");
// or bugtrap();
}
Errr... not trying to teach egg sucking here - I'm confident the kernel guys are far better at this stuff than me!
Of course. You can also contact with developers via "Ros-dev" mailing list and on #reactos IRC channel.Am I allowed to post comments into that bug report?.. Dunno if there's any interest in comments.
Agree.The code looks a bit unsafe.
Nevertheless they make errors.Errr... not trying to teach egg sucking here - I'm confident the kernel guys are far better at this stuff than me!
Thanks.
Thanks. I'll bear that in mind
BTW before any prpgrammers rip the idea to shreds - yep I know simply testing for NULL would work as well but strempty() serves a dual purpose and is handy for general string handling - hence I can include it pretty well throughout all my code. I can't remember the last time I ever had a bug due to a pointer error since I adopted a safer pointer-handling strategy.
A kinda C-safe way of doing a BASIC IF s$ <> ""
Guess I should retire raw pointers and move to String objects huh?
BTW before any prpgrammers rip the idea to shreds - yep I know simply testing for NULL would work as well but strempty() serves a dual purpose and is handy for general string handling - hence I can include it pretty well throughout all my code. I can't remember the last time I ever had a bug due to a pointer error since I adopted a safer pointer-handling strategy.
A kinda C-safe way of doing a BASIC IF s$ <> ""
Guess I should retire raw pointers and move to String objects huh?
maxmax says:hto wrote:"String objects" are usually used in the kernel instead of raw pointers. String object contains pointer, length and maximum length.
No divide by zero in that code. Because sizeof(WCHAR) cannot be 0.
I was thinking along the lines of what happens with dividing zero by n not divide n by zero (let alone the issue of NULL pointers/unassigned object happening due to other code being changed at some future time)... Can't comment fully as I can't see the preconditions but it has the potential to divide zero .length (0/n) overflow.
Guess you're right here but this has set me thinking, given me a headache and certainly made me realise how much we take certain logical constructs for granted and accept them without thinking about them!. Interesting.
Possibly also because out of habit I'd normally avoid it so I've just had to go check to see if my own compilers let me do it. Borland does, although I'm not sure what the effect would be of having the result of such a logical construct floating around in the code. Guess if everyone understands and it's clear what the intention is there's not a problem. (same as with asm: a xor a as equivalent to a=0 being transparently obvious to asm programmers) It certainly shows how our internal concepts affect the way we code.
It might be a philosophical point whether zero divided by any number is zero or "undefined" - I'm leaning on VERY old-fashioned school maths which accepted that you couldn't divide "nothing" into n parts although zero was assumed as the result if it were possible. Modern thinking would be to allow the impossible operation and assume the dividend value was unchanged as 0
A a side issue - anyone interested in making their brain hurt even more can find some interesting reading - for example what is 0/0 ? (http://en.wikipedia.org/wiki/James_Ande ... scientist)) on transreal arithmetic.
According to this it varies between 0 and infinity depending on the math system. How bizarre. Damn, I'll be thinking about this one all night now. Tsk, these pesky mathematicians i'm off to get some Anadins!
PS If anyone else is puzzled you can try the code below online which shows that, yes, C does accept it and returns zero without problems - http://compiler.amadis.sytes.net (Win32/DOS only)
Code: Select all
#include <stdio.h>
void main()
{
int i=0;
int n=10;
printf("Dividing...\n");
int q=i/n; // See if the compiled code allows it...
printf("Hooray - didn't crash and %i / %i was %i\n",i,n,q);
}
Who is online
Users browsing this forum: No registered users and 29 guests