I run Freebsd 13-RELEASE as virtualbox guest with virtualbox-ose-additions 6.1.20 from package After a mount_vboxvfs with no issue, the virtual machine reboot each time i try to acces the shared folder
Do you have vboxguest.ko loaded and are you sure you're using virtualbox-ose-additions 6.1.20? I believe this issue has been resolved with this commit and included with 6.1.18_1: https://cgit.freebsd.org/ports/commit/?id=8a311de0cb804d8b135413884b4fb336d287ad5a I just tried with 13.0-RELEASE vm from https://app.vagrantup.com/bento/boxes/freebsd-13.0 and upgraded virtualbox-ose-additions-nox11 to 6.1.20, the shared folder works fine.
(In reply to Li-Wen Hsu from comment #1) vboxguest.ko is loaded and virtualbox-ose-additions 6.1.20 from ports
Hi, just add -by my usage cases- that virtualbox-ose-addition recent update has solved this issue in the Windows10 hosted Freebsd 13 virtual machine, but it still remains same (machine reboots as attempting to open the shared folder) on the Ubuntu hosted VirtualBox, same version in both hosts, 6.1.19
(In reply to mauro from comment #3) Can you produce a core dump and/or a backtrace of the crash? You should configure a dump device in FreeBSD. Without such information it's really hard to guess what is going on.
Good morning Guido, thanks for your reply. I'd like to proceed as per your suggestion, the fact is that I'm taking knowledge of Freebsd since less than one month, And don't know anything on how to produce what requested to investigate the issue. If you think it is good to instruct me step by step for this, I'm ready from my side. Furthermore I can tell that meantime I also installed a NomadBSD 1.4 system (based on FreeBSD 12.2 kernel) as VirtualBox machine, and it does not encounter any problem in accessing the setted shared folder both in Windows host and in Ubuntu as well. The Guest Additions installation was already included in the system distribution. Regards
Good morning Guido, thanks for your reply. I'd like to proceed as per your suggestion, the fact is that I'm taking knowledge of Freebsd since less than one month, And don't know anything on how to produce what requested to investigate the issue. If you think it is good to instruct me step by step for this, I'm ready from my side. Furthermore I can tell that meantime I also installed a NomadBSD 1.4 system (based on FreeBSD 12.2 kernel) as VirtualBox machine, and it does not encounter any problem in accessing the setted shared folder both in Windows host and in Ubuntu as well. The Guest Additions installation version is 5.2.44_3, and was already included in the system distribution. Regards
(In reply to Guido Falsi from comment #4) Please, Could you explain how to produce a core dump or a backtrace of the crash? Thanks
To have the kernel save a core dump you need the machine (virtual or physical) to have more swap than ram and configure it to perform the dump with dumpdev="AUTO" in /etc/rc.conf. A machine without any swap (which is a relatively common setup for virtual machines) has no way to save a kernel core dump. But to get actually useful data you should be running a debugging kernel. I think, especially since we're talking about virtual machines, it would be easier for you to install a VM with a snapshot of 14-CURRENT, that comes with debugging kernel by default and see if the problem happens there, you should then be dropped in the debugger an automatically get a backtrace that could help investigating the issue. Use the "bt" debugger command to print it again (the debugger should do that automatically) Having a backtrace is no warranty of a resolution but would at least give an idea to what part of the kernel to start looking at. You should also configure enough swap so you can save a core dump that can be analyzed later. To get that at the debugger prompt use the "save" command, followed by "reboot". You can get head snapshots from https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/14.0/
(In reply to Guido Falsi from comment #8) Ok, if it is only me having this issue limited to Ubuntu host system, I give up. The action described are over my capacity to apply them and hope next GA versions could have fixed this. I can survive meantime, as needing a folder sharing in Ubuntu host, involves a minimum part of my cases. Thank you again
I have the same issue than Mauro with ubuntu host . I give up too, the action described by Guido is too complicated for me I wait for next GA versions Thanks
Unluckily debugging is not something that happens by itself. Anyway, can you state some more details of your setup so maybe someone else can try to replicate the issue? Some requires information: Ubuntu version? VirtualBox version installed on host (from official ubuntu repo?) Hardware being used (I guess amd64, called x86_64 in linux)? Can you state your CPU? (while improbable, the problem could also be hardware related) (can't think of other relevant details but anyone can post requests for new details if needed)
(In reply to Guido Falsi from comment #11) Host : Ubuntu 20.04.2 LTS x86_64 Virtualbox version on host : 6.1.22 r144080 cpu info : dmidecode 3.2 Getting SMBIOS data from sysfs. SMBIOS 2.8 present. Handle 0x003D, DMI type 4, 42 bytes Processor Information Socket Designation: SOCKET 0 Type: Central Processor Family: Core i5 Manufacturer: Intel ID: C3 06 03 00 FF FB EB BF Signature: Type 0, Family 6, Model 60, Stepping 3 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz Voltage: 1.2 V External Clock: 100 MHz Max Speed: 3800 MHz Current Speed: 3200 MHz Status: Populated, Enabled Upgrade: Socket BGA1155 L1 Cache Handle: 0x003F L2 Cache Handle: 0x003E L3 Cache Handle: 0x0040 Serial Number: Not Specified Asset Tag: Fill By OEM Part Number: Fill By OEM Core Count: 4 Core Enabled: 4 Thread Count: 4 Characteristics: 64-bit capable
(In reply to Guido Falsi from comment #11) yes. -Ubuntu host system amd64 = 20.04 LTS. -Storage memory* = 128 Gb -RAM = 16 Gb -swap space = 6 Gb -CPU = Intel i7 dual core -Video adapter = dual Intel HD 5500 integrated + AMD Radeon M330 2Gb -VirtualBox installation = v. 6.1.19, with Extensions Pack, -VirtualBox .deb package downloaded from the Virtualbox site page Virtual Machine config: -Storage memory** = 256 Gb -RAM = 8 Gb -Video Memory = 128 Mb -cpu cores = 1 -Video adapter = VBoxSVGA (also works with VBoxVGA) -USB filter = enabled -Shared folder = enabled on /home/myuser/ with automount and complete control, also added user permissions for vboxsf with "sudo adduser $USER vboxsf" Hardware config (HP laptop): -Storage memory = SSD 1 Tb -RAM = 16 GB -CPU = Intel i7 dual core -Video adapter = dual Intel HD 5500 integrated + AMD Radeon M330 2Gb -system booting on SSD disk = Windows 10 20H2 -Bios UEFI + Legacy Freebsd 13 guest config: -Storage memory** = 256 Gb -RAM = 8 Gb -swap space = 2 Gb -VBox Guest Additions = latest update of virtualbox-ose-additions from FreeBSD packages repository *Ubuntu host system 20.04 LTS is installed in a bootable USB3 pendrive of 128 Gb **FreeBSD 13 guest system is installed in a USB3 pendrive of 256 Gb which can also be booted from inside a Virtualbox session even hosted in a smaller storage space. Works same both as a physical USB3 bootable volume, and also as virtual machine handled in a VirtualBox session. A NomadBSD 1.4 system installed in same mode (physical USB3 bootable also handled by a VirtualBox session) does not give this issue when used as virtual machine in VirtualBox Ubuntu hosted. Shared folders are normally accessible in Ubuntu like in Windows. Guest Additions are already included in this release, version 5.2.44_3 (legacy). Thank you
Created attachment 224876 [details] dumped core
dumped core file if it can help
(In reply to philippe972 from comment #14) You did it Philippe, useful job from you rather than me :) Thanks
(In reply to philippe972 from comment #15) The dump you posted has some useful information. It indicates the issue happens in the vboxfs_readdir() function. Unluckily there are no details about where more exactly and due to what cause. also this line: current process = 866 (gvfs-udisks2-volume) makes me suspicious. Are you automounting vbox shared folders from some desktop environment? Not sure the FreeBSD additions shared folder driver supports that. If you're not already doing it, could you mount the shared folder at boot from fstab, with a line like this: VMs /mnt/vbox vboxvfs rw,late,uid=1001,gid=1001 0 0 (VMs being the name of the shared folder you gave in virtualbox, the other fields should be self explanatory) Nor sure I can help much more.
(In reply to Guido Falsi from comment #17) I think I have found the beginning of an explanation : when sharefolder name is initialy lowercase all works fine with the mount_vboxvfs command I also tried to rename sharefolder name uppercase to lowercase, the mount_vboxvfs command make the VM reboot this is the first result of my research
(In reply to philippe972 from comment #18) Are you sure the problem is with upper/lower case? While possible it looks strange. Could it be caused by non ascii characters instead? would make much more sense.
in my personal case, this is the mount command I give (working in Windows host, reboot the machine in Ubuntu host): doas mount -t vboxvfs mauro /home/mauro/shared/ where mauro is the Virtualbox shared folder choosen in Ubuntu (path home/mauro) but also in Windows (Users/mauro). And shared is the folder I created inside /home/mauro/ in Freebsd guest to access the shared folder
For the bug to be found in the normal way, please prefix the summary line. Probably: emulators/virtualbox-ose-additions Thanks
Created attachment 227816 [details] proposed patch to patch uninitialized pointer to node
For the tests I used the VM-IMAGES, release one (vm1) and snapshot (vm2). vm1: releng/13.0-n244733-ea31abc261f, additions 6.1.22 r144080 vm2: stable/13-n247062-c4bd6b589c8, additions 6.1.26 r145957 I saw no problem on Ubuntu 20.10 with 6.1.16-dfsg-6~ubuntu1.20.10.1. Both VMs were crashing under 20.04 with 6.1.26-dfsg-3~ubuntu1.20.04.1. For my tests I focused on host Ubuntu 20.04, release vm1. I mounted the shared directory coming from host to /shared on guest. Creating dirs, removing them seemed ok. It was always crashing in vboxfs_readdir() on obviously bogus address: 0x15 or something very similar. I checked the sources of virtualbox-ose-additions-nox11-6.1.26, the src/VBox/Additions/freebsd/vboxvfs/vboxvfs_vnops.c:1092 1092 if (strcmp(dirent->sf_entry.d_name, ".") == 0) { 1093 node = dir; 1094 } else if (strcmp(dirent->sf_entry.d_name, "..") == 0) { 1095 node = dir->sf_parent; 1096 if (node == NULL) 1097 node = dir; 1098 } else { 1099 #if 0 1100 node = vsfnode_lookup(dir, dirent->sf_entry.d_name, VNON, 1101 0, &dirent->sf_stat, vsfnode_cur_time_usec(), NULL); 1102 if (node == NULL) 1103 panic("sffs_readdir() lookup failed"); 1104 #endif 1105 } 1106 1107 if (node) 1108 dirent->sf_entry.d_fileno = node->sf_ino; 1109 else 1110 dirent->sf_entry.d_fileno = 0xdeadbeef; It seems the vboxfs_node node pointer is being used uninitialized. I don't get it how come it works under Ubuntu 20.10 (coincidence ?). But setting the pointer to NULL did the trick: 1012 struct vboxfs_node *node = NULL; I've never did write any patch for public, I've attached one.
(In reply to martin ilavsky from comment #23) God catch, the fact that the else block is surrounded by #if 0 definitely makes it possible to use the node variable undefined. Your patch would prevent a crash due to referencing a random pointer, but I'm not able to review it for possible further unwanted consequences or crashes down the line. That dirent->sf_entry.d_fileno = 0xdeadbeef; looks dangerous and I don't know enough aboud the vfs interface to understand that. The commented code explicitly calls panic if node == NULL. This worries me a little. I could not find any information regarding vsfnode_lookup(), so I cannot guess what the commented code is trying to do. So to sum up, avoiding use of undefined variable is anyway correct, and I'm going to test it and also commit it probably. BUT the code path defining "dirent->sf_entry.d_fileno = 0xdeadbeef;" looks a little fishy to me and could cause issues later when using the FS. I'd really like to have someone with better knowledge of the file system interface review this, so I don't think the issue should be closed with this patch.
(In reply to martin ilavsky from comment #23) If you could shed some light on that vsfnode_lookup() function purpose it would be of great help to try to understand what is happening here.
(In reply to Guido Falsi from comment #25) I saw the code for the first time yesterday, I was debugging the dumps somebody mentioned on the forums. I'm trying to get more familiar with the module but there's lots of stuff to understand. During my tests I found out (with or without my patch) if you run ls in loop long enough (matter of seconds) module reports back out of memory and you can't browse the shared directory at all. Happens on all combinations of host - FreeBSD guest I tried. The only option to make it work again is to unmount the share and unload the module.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1b2394551c038558810be8bf396462174db334be commit 1b2394551c038558810be8bf396462174db334be Author: Martin Ilavsky <ilavsky.martin@gmail.com> AuthorDate: 2021-09-11 20:38:50 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2021-09-11 20:38:50 +0000 emulators/virtualbox-ose-additions: Assign default value to pointer In the virtualbox virtual filesystem code we ship as a patch some code in an else block is commented out. This produces a code path in which a pointer variable is dereferenced in an unassigned state, causing random crashes. Lacking a better fix, give a default value of NULL to the pointer, which at least avoids the random pointer dereference issue. PR: 255386 emulators/virtualbox-ose-additions/Makefile | 1 + .../files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-)
@martin I committed your patch, since it corrects an actual issue (uninitialized random pointer dereference), but as I said I'm not sure this fixes the whole issue, and more problems are lurking in the code.
(In reply to Guido Falsi from comment #28) Thanks. I agree. I was not able to find any reference to vsfnode_lookup(), neither in FreeBSD 12/13 src nor in the VirtualBox code (5.x and 6.x). But it seems the code was borrowed from the Solaris additions. There are more comments in the code too. Slowly trying to understand it.
A commit in branch 2021Q3 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d557edd568b5e127b6f8eefad4ba071c3aa123f9 commit d557edd568b5e127b6f8eefad4ba071c3aa123f9 Author: Martin Ilavsky <ilavsky.martin@gmail.com> AuthorDate: 2021-09-11 20:38:50 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2021-09-12 12:11:53 +0000 emulators/virtualbox-ose-additions: Assign default value to pointer In the virtualbox virtual filesystem code we ship as a patch some code in an else block is commented out. This produces a code path in which a pointer variable is dereferenced in an unassigned state, causing random crashes. Lacking a better fix, give a default value of NULL to the pointer, which at least avoids the random pointer dereference issue. PR: 255386 (cherry picked from commit 1b2394551c038558810be8bf396462174db334be) emulators/virtualbox-ose-additions/Makefile | 1 + .../files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c43e12a46f329c2ff336f06c61a6eb6be0ac9108 commit c43e12a46f329c2ff336f06c61a6eb6be0ac9108 Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2021-10-17 09:29:56 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2021-10-17 09:32:33 +0000 emulators/virtualbox-ose-additions-legacy: Import improvements from non legacy port Import changes from commit 1b2394551c0385 to legacy port: In the virtualbox virtual filesystem code we ship as a patch some code in an else block is commented out. This produces a code path in which a pointer variable is dereferenced in an unassigned state, causing random crashes. Lacking a better fix, give a default value of NULL to the pointer, which at least avoids the random pointer dereference issue. PR: 255386 Alsso import fix for building on recent head from cec55f41e10f13: Fix build after head commit b4a58fbf640409a1 (vfs: remove cn_thread) MFH: 2021Q4 emulators/virtualbox-ose-legacy/Makefile | 2 +- ...VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c | 25 +++++++++------------- 2 files changed, 11 insertions(+), 16 deletions(-)
A commit in branch 2021Q4 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=705ba6bb024b625f3914f56cdc9f92334b0c7ff7 commit 705ba6bb024b625f3914f56cdc9f92334b0c7ff7 Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2021-10-17 09:29:56 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2021-10-17 09:33:39 +0000 emulators/virtualbox-ose-additions-legacy: Import improvements from non legacy port Import changes from commit 1b2394551c0385 to legacy port: In the virtualbox virtual filesystem code we ship as a patch some code in an else block is commented out. This produces a code path in which a pointer variable is dereferenced in an unassigned state, causing random crashes. Lacking a better fix, give a default value of NULL to the pointer, which at least avoids the random pointer dereference issue. PR: 255386 Alsso import fix for building on recent head from cec55f41e10f13: Fix build after head commit b4a58fbf640409a1 (vfs: remove cn_thread) MFH: 2021Q4 (cherry picked from commit c43e12a46f329c2ff336f06c61a6eb6be0ac9108) emulators/virtualbox-ose-legacy/Makefile | 2 +- ...VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c | 25 +++++++++------------- 2 files changed, 11 insertions(+), 16 deletions(-)
Sorry, ignore my flag for feedback on the patch. Now I see (comment #28): > I committed your patch, …