Now usually you have a repository path of /home/svn/repo , the only chmod you apply is on repo directory
but this is not the case. You should chmod the entire svn home directory. Works for me.

Below is what I did to solve the issue.

chmod -R 755 /home/svn

Below are the procedures I took:

Step 1: Start FreeBSD. Press enter key for FreeBSD boot loader.
Step 2: When FreeBSD’s welcome screen will prompt up, press space bar to pause the booting.Refer to below diagram.

Step 3: Type number 4 in the welcome screen. This will boot up in single user mode.
Step 4: Wait until you will be prompted with the below line.

When prompted Enter full pathname of shell or RETURN for /bin/sh:

Step 5: Press entry key to prompt you to the shell.
Step 6: Execute the following commands.

# mount -u /
# mount -a

Note:
If issuing the command mount -u will prompt you “Filesystem not clean – run fsck”.Just execute the command fsck. Then proceed to mount -a. Refer to below error message.

Step 7: After execution of the above commands. Execute below commands.
This will prompt you to change the root password.

# passwd

Step 8: Reboot FreeBSD or type exit.

# exit
# reboot

This was tested for FreeBSD 7.1 but most likely this will also work for other version
of FreeBSD.

First way, execute the disk manager toolkit of vmware :

vmware-vdiskmanager.exe -x 50GB “FreeBSDclone.vmdk”

Second way, from the virtual machine settings :

Click add hardware and click hard disk then next.

Click add a new virtual disk space then next.

Choose SCSI and leave the others unchecked.

Allocate the disk space you want.
Finish.

Then boot your freebsd virtual machine to configure the newly added disk space.
Step 1 : Login as root and run the sysinstall(Note that you can also do this using the fdisk if you are familiar with the commands).

Step 2 : Go to configure then fdisk and choose the below drive(that is the newly added disk space).

Step 3 : Create slice and allocated the whole space.

Step 4 : Choose the disk label tool then Create label. Then finish.

Step 5 : Mount the newly added space in /etc/fstab.
Step 6 : Move files in the newly added space.
For my case my newly added space is mounted in /usr/ext/local
and I’m having space trouble for /usr so I decided to move my
/usr/ports to /usr/ext/local.

Then create a symlink to /usr/ports.

Note :
You can also use growfs command but it’s a different approach.

This bug is kind a weird and really hard to trace. To make things worst MSDN some what provides a misleading documentation. I wasted 4 days working on this weird bug and ended up to have an easy fixed. I googled around but ended up to have a handful of information and found out that alot of people did encounter this kind of problem but no providing fixed.

Personally when I think of an access violation problem the only stuff that I thought of something related to pointers. It’s either you use a pointer without proper memory allocation and initialization. Or you use/access a pointer that was no longer on the heap. With these stuffs on my head I checked on every pointers that I had and found out they were all properly taken care of. And to make my pointers safe I even use smart pointers but still the problem exist.

I open the crashed dump and analyzed, I got the below output:
CRASH DUMP SCREENSHOT LINK

As you may see on the stack frames that the crashed occurred on the user32.dll which is one of the fundamental windows DLL. And it was on the call of CreateWindowEx that lead to crashed. I thought of I’m feeding the CreateWindowEx API with invalid data but I check every variables and guess what they were all valid. So I thought of that this was a f*cking windows API problem.

Then I found this URL http://blogs.msdn.com/oldnewthing/archive/2006/09/20/763727.aspx and this truly saves my day.

Solution to this problem :
1) Free resources used upon unloading the DLL.
2) For every window handle created make sure that it was destroyed upon exiting the DLL.
3) For every registered window class make sure that it was unregistered upon exiting the DLL.
4) For every child window class make sure that it was destroyed and unregistered before destroying the parent window class.

The number 4 was the one caused my problem. And that is why I say that MSDN was kind a providing a misleading document. If you read on the DestroyWindow() and Unregisterclass() on msdn documentation you might conclude that ; ok I’d DestroyWindow on the parent window I should no longer problem the associated child caused it was also destroy. But hey I should unregister the child window class caused it causes a memory leak on the heap but before unregistering the child window class I should destroy first all its created windows.

I might be doing an misinterpretation on the document. I think the MSDN tells us that upon exiting on the WindProc of parent window you should do atleast these :

DestroyWindow(ParentWindow);
Unregisterclass(“childClassWindow”,Instance);
Unregisterclass(“parentClassWindow”,Instance);

It would be ideally good if DestroyWindow also unregister the child class window.

References :

http://msdn.microsoft.com/en-us/library/ms644899(VS.85).aspx (DestroyWindow)
http://msdn.microsoft.com/en-us/library/ms632682(VS.85).aspx (Unregisterclass)

http://blogs.msdn.com/oldnewthing/archive/2006/09/20/763727.aspx

After googling around the net for some time I was able to found out that it was the unallocated pointer or uninitialized pointer that causes the crashed. There was a struct pointer that was used without allocating memory or initializing to null.

Below Example :

typedef struct sample_struct
{
     int x;
     int y;
} non_pointer, *pointer_var;

int main ()
{
     pointer_var my_var = new non_pointer;

     // operation using my_var
     ..

     delete my_var;

/* or another way around */

     pointer_var my_var = NULL;

     // operation using my_var
     ..

     if (my_var != NULL) // upon freeing the pointer
     {
     delete my_var;
     }
}

This will make the application safe from memory leak and access violation. But it makes me wonder why it doesn’t crash on XP while in Vista crashes. A colleague told me that Vista is already strict on memory leak while on XP it just ignores and stays on the memory stack.