Ros-dev December 2010

ros-dev@reactos.org

20 participants
15 discussions

Re: [ros-dev] [ros-diffs] [tkreuzer] 50243: [CMAKE] Add generation of a depencency graph for shared libraries. The output is a graphml file. Can be enabled with GENERATE_DEPENDENCY_GRAPH switch.

by Ged Murphy

I didn't know about this feature. Will this help the effort towards a minwin effort in fixing the dependency hierarchy (mess)? Ged. On 31 December 2010 16:49, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Fri Dec 31 16:49:49 2010 > New Revision: 50243 > > URL: http://svn.reactos.org/svn/reactos?rev=50243&view=rev > Log: > [CMAKE] > Add generation of a depencency graph for shared libraries. > The output is a graphml file. Can be enabled with GENERATE_DEPENDENCY_GRAPH > switch. > >

13 years, 8 months

Is Testman and DBG-Server on strike or on Christmas holidays?

by victor martinez

I have asked several times in #reactos and in #reactos-dev channels, so now time to ask again here: What happens with the server? We are commiting a lot ( more than 25 commits/days last days) and we dont know if: 1)One of those commits (hopefully not) has broken building.. 2)One of those commits (hopefully not) has broken booting.. Both of these are pain in the a...if regtesting is needed. So: Can anyone fix this situation asap? Merry Thanks and Many Christmas ;)

13 years, 8 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 50217: [CMAKE] LD is stupid and doesn't handle stdcall decoration as proper as dlltool does (after we provided a patch). Passing --kill-at, also kills C++ mangled names and exports with ...

by Colin Finck

tkreuzer(a)svn.reactos.org wrote: > LD is stupid and doesn't handle stdcall decoration as proper as > dlltool does (after we provided a patch) [...] Wouldn't it have been easier to just provide a similar patch for LD then? It was a matter of changing a strchr() call to strrchr()... (http://sourceware.org/bugzilla/show_bug.cgi?id=9766) We can always use a patched binutils version in the next RosBE if the patch is not applied to the upstream source in time. Cheers, Colin

13 years, 8 months

Re: [ros-dev] [ros-diffs] [cgutman] 50077: [USBDRIVER] - Fix a bug that resulted in us onl

by Pierre Schweitzer

Hi, > Author: cgutman > Date: Tue Dec 21 04:35:12 2010 > New Revision: 50077 > > URL: http://svn.reactos.org/svn/reactos?rev=50077&view=rev > Log: > [USBDRIVER] > - Fix a bug that resulted in us only copying half of the old keyboard data > - CID 10402 > > Modified: > trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c > > Modified: trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/nt4compat/usbd… > ============================================================================== > --- trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c [iso-8859-1] Tue Dec 21 04:35:12 2010 > @@ -277,7 +277,7 @@ > } > > // Save old keyboard data > - RtlCopyMemory(pdev_ext->kbd_old, data, sizeof(data)); > + RtlCopyMemory(pdev_ext->kbd_old, data, 8); > > // resubmit the urb > status = usb_submit_urb(pdev_ext->dev_mgr, purb); This change is really dangerous and should be changed to a correct fix. Using magic values on memory copying is a bad idea. Using magic values (in general) is a bad idea. Please provide a better fix without magic value. Regards, P. Schweitzer

13 years, 8 months

Re: [ros-dev] [ros-diffs] [dgorbachev] 50117: Marco Radossevich <fwdprojects=at=email=dot=it>, a.k.a. forart: "Just two important examples that involved my contributions: UniATA & FullFAT." No code changes. See thread <http...

by Ged Murphy

hahaha -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dgorbachev(a)svn.reactos.org Sent: 24 December 2010 01:59 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dgorbachev] 50117: Marco Radossevich <fwdprojects=at=email=dot=it>, a.k.a. forart: "Just two important examples that involved my contributions: UniATA & FullFAT." No code changes. See thread <http... Author: dgorbachev Date: Fri Dec 24 01:59:13 2010 New Revision: 50117 URL: http://svn.reactos.org/svn/reactos?rev=50117&view=rev Log: Marco Radossevich <fwdprojects=at=email=dot=it>, a.k.a. forart: "Just two important examples that involved my contributions: UniATA & FullFAT." No code changes. See thread <http://www.reactos.org/forum/viewtopic.php?f=14&t=8809> for more details. Modified: trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h trunk/reactos/drivers/filesystems/fastfat_new/rw.c trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h Modified: trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… ============================================================================== --- trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h [iso-8859-1] (original) +++ trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h [iso-8859-1] Fri Dec 24 01:59:13 2010 @@ -80,7 +80,7 @@ CcUnpinData((xContext)->Bcb); \ (xContext)->Bcb = NULL; \ } \ - + #define FatPinEndOfPage(xContext, xType) \ Add2Ptr((xContext)->Buffer, (xContext)->ValidLength, xType) Modified: trunk/reactos/drivers/filesystems/fastfat_new/rw.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… ============================================================================== --- trunk/reactos/drivers/filesystems/fastfat_new/rw.c [iso-8859-1] (original) +++ trunk/reactos/drivers/filesystems/fastfat_new/rw.c [iso-8859-1] Fri Dec 24 01:59:13 2010 @@ -36,7 +36,7 @@ FatCompleteRequest(IrpContext, IrpContext->Irp, STATUS_SUCCESS); return STATUS_SUCCESS; } - + OpenType = FatDecodeFileObject(FileObject, &Vcb, &Fcb, &Ccb); DPRINT("FatiRead() Fcb %p, Name %wZ, Offset %d, Length %d, Handle %p\n", Modified: trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/storage/ide/uniata… ============================================================================== --- trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h [iso-8859-1] (original) +++ trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h [iso-8859-1] Fri Dec 24 01:59:13 2010 @@ -43,4 +43,4 @@ }; #endif //__cplusplus -#endif //__DBG_DUMP_TOOLS__H__ +#endif //__DBG_DUMP_TOOLS__H__

13 years, 8 months

[ros-diffs] [fireball] 50108: [NTOS] - Fix memory region size calculation in MemoryBasicInformation in certain cases

by victor martinez

I have a doubt: ============================================================================== --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Wed Dec 22 21:59:27 2010 @@ -2446,6 +2446,9 @@ /* Check if this VAD is too high */ if (BaseVpn < Vad->StartingVpn) { + /* Stop if there is no left child */ + if (!Vad->LeftChild) break; + /* Search on the left next */ Vad = Vad->LeftChild; } @@ -2453,6 +2456,11 @@ { /* Then this VAD is too low, keep searching on the right */ ASSERT(BaseVpn > Vad->EndingVpn); + + /* Stop if there is no right child */ + if (!Vad->LeftChild) break; + + /* Search on the right next */ Vad = Vad->RightChild; } }======================================================== Look these lines: + /* Stop if there is no left child */ + if (!Vad->LeftChild) break; + /* Stop if there is no right child */ + if (!Vad->LeftChild) break; 1) Is there a typo in the copy-pasta condition? 2) Is the comment wrong or misleading? 3) Am I a complete noob? I think the order is 3), 1), 2) One of the latest changes has made ReactOS totally uninstallable(12 tries /12 fails) using less than 192MB Ram.It halts in first stage during copying files. Merry Christmas!!

13 years, 8 months

[ros-diffs] [pschweitzer] 50090: [FASTFAT] Fix for a buffer overflow and then a buffer overrun (if ever it fixes something) The way filenames are handled for FAT entries should be REALLY simplified. This would...

by James Tabor

Hi! I guess once long tyme ago, there was a little file called dos.h! Need this #define _A_VOLID 0x08 /* Volume ID file */ VolumeLabelDirEntry.Fat.Attrib = 0x08; }

13 years, 8 months

Unable to get wubble launch working with ua-ros-pkg

by GANESH KUMAR

I'm not able to get the wubble simulation working for the ua-ros-pkg at: http://code.google.com/p/ua-ros-pkg [Note: I'm a new comer to ROS] Summary of Issue: I am using the Q&A Format provided by the site above. a. What steps will reproduce the problem? 1. Follow http://code.google.com/p/ua-ros-pkg/wiki/DeveloperInstall to install uav-ros-pkg packages 2. Run roslaunch wubble_mapping simulation.launch b. What is the expected output? What do you see instead? Expected output: Runs as given in http://code.google.com/p/ua-ros-pkg/wiki/ClassInstructions. Observed output: -------------- while processing /opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/empty_blocks_world.launch: while processing /opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/world_common.launch: Invalid roslaunch XML syntax: [Errno 2] No such file or directory: u'/opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/world_common.launch' ------------ c. What version of the product are you using? On what operating system? Latest trunk, on Ubuntu 10.04 /Lucid. d. Additional Notes? world_common isn't there in the given files, and neither does it get generated during the build. Also, while running make-all.sh I get 'Built 46 packages with 1 failure'. My gearbox has the following issue during the build: ========================== mkdir -p build/gearbox-svn/build cd `rospack find gearbox` && patch -d build/gearbox-svn/src/hokuyo_aist/python --verbose < `rospack find gearbox`/aist_python_mt.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- CMakeLists.txt 2010-11-05 17:13:52.719057243 -0700 |+++ CMakeLists.txt.ros 2010-11-05 17:12:30.921672551 -0700 -------------------------- Patching file CMakeLists.txt using Plan A... Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. Hunk #1 ignored at 41. 1 out of 1 hunk ignored -- saving rejects to file CMakeLists.txt.rej done =========================== I wonder whether this is causing the problem, and am not totally clear as to how to correct this. Thanks! -- Ganesh $ g++ file.c -fblocks -Wall /usr/lib/bundle1.o -arch x86_64 -o file.out

13 years, 8 months

Re: [ros-dev] [ros-diffs] [rmessiant] 50076: [CLASSPNP] - Use correct type in sizeof expression (CID 1646 and 10401). - Simplify signature define (CID 3653 and 3654). - Remove funky 0xFF characters.

by Timo Kreuzer

Am 21.12.2010 01:41, schrieb rmessiant(a)svn.reactos.org: > Author: rmessiant > Date: Tue Dec 21 00:41:52 2010 > New Revision: 50076 > > ... > > -#define DICTIONARY_SIGNATURE (((ULONG)'dict'<< 32) + 'sig ') > - > -struct _DICTIONARY_HEADER { > +#define DICTIONARY_SIGNATURE 'dsig' > + I think it was supposed to be something like (ULONGLONG)'dictsig '

13 years, 8 months

Heap Issues

by James Tabor

I've tested my patches with 49720 so far the wine user Dialog works. Upping to 50046 and repeating the test since 50000, this happens, (subsystems/win32/win32k/ntuser/window.c:2067) co_UserCreateWindowEx(): NCCREATE message failed (subsystems/win32/win32k/ntuser/window.c:2339) co_UserCreateWindowEx failed! kdb:> bt Eip: <ntdll.dll:92b1> lib/rtl/heap.c:358 (RtlpRemoveFreeBlock@16) Frames: <ntdll.dll:b189> lib/rtl/heap.c:2193 (RtlAllocateHeap@12) <user32.dll:32610> dialog.c:157 (DIALOG_get_info) <user32.dll:3369c> dialog.c:1577 (DefDlgProcA@16) <user32.dll:495dc> message.c:1091 (@IntCallWindowProcW@28) <user32.dll:49ead> message.c:2449 (User32CallWindowProcFromKernel@8) <ntdll.dll:7a84> <user32.dll:542c5> window.c:409 (CreateWindowExA@48) <user32.dll:343bf> dialog.c:925 (DIALOG_CreateIndirect) <user32.dll:352c0> dialog.c:1764 (DialogBoxParamA@20) <user32_winetest.exe:2055c> <user32_winetest.exe:22065> <user32_winetest.exe:a36e6> <user32_winetest.exe:a38fb> <user32_winetest.exe:a3d95> <user32_winetest.exe:a3dde> it faults at 0x00000004,,,....

13 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev December 2010