IRC channel logs

<rickmasters>Mikaku: I'm working on a response for your question regarding the Fiwix issue

<Mikaku>rickmasters: yes, I was completely unable to reproduce the segfault :-(

<rickmasters>Mikaku: I'm running in graphics mode so it's not easy to cut and paste the segfault output

<Mikaku>that's why I thought that if you can provide the kernel output on that segfault (with registers, etc.) it might help me

<Mikaku>you can redirect the console to the serial device

<rickmasters>Mikaku: couple things to check: are you running stock kernel? You'll need to define CONFIG_LAZY_USER_ADDR_CHECK

<Mikaku>add the kernel parameter 'console'/dev/ttyS0'

<Mikaku>yes, CONFIG_LAZY_USER_ADDR_CHECK is enabled by default

<Mikaku>add the kernel parameter 'console=/dev/ttyS0'

<rickmasters>Another thing, if you just add *((unsigned int *) 0) = 0; into the code you can get a vma dump and check the stack page mapping

<Mikaku>or you can provide me the binary that segfaults

<Mikaku>BTW, where did you compile such binary? are you using FiwixOS?

<rickmasters>I'm running FiwixOS-3.1 and then I copy the 1.4.0 kernel to /boot and reboot.

<rickmasters>I'll work on uploading the binary to the Issue

<rickmasters>I'm booting off the raw hard drive image, its not clear how I can change the kernel parameters.

<Mikaku>rickmasters: you can pass the '-kernel' parameter to QEMU and instruct the kernel to boot from disk specifying the root device with '-append root=/dev/hda2'

<Mikaku>this way you'll save the tedious task to copy the kernel to /boot all the time

<Mikaku>qemu-system-i386 -hda <FiwixOS image> -kernel /path/to/fiwix -append "root=/dev/hda2 console=/dev/ttyS0"

<rickmasters>I'm able to change the kernel that way (thanks) but still cannot get a serial console

<Mikaku>rickmasters: <https://pastesite.org/view/7621c154> <- I recommend you this

<rickmasters>I'm running over ssh and I get "gtk initialization failed", even with -serial stdio

<Mikaku>'-debugcon stdio' is even easier since all kernel messages are shown in the terminal where you started QEMU

<Mikaku>it requires CONFIG_QEMU_DEBUGCON enabled in the kernel

<Mikaku>you can omit the kernel parameter 'bga=1024x768x32' since you are running QEMU over SSH

<rickmasters>well, -nographic gets me startup messages but no login prompt

<rickmasters>Mikaku: how do I omit the kernel parameter?

<Mikaku>I meant that you don't need to specify the parameter bga= since you are running QEMU over SSH

<Mikaku>this parameter won't be useful for you

<rickmasters>oh, from the pastbin - yeah I didn't include that parameter

<Mikaku>ok

<rickmasters>I used console=/dev/ttyS0

<Mikaku>perfect, now you can use 'picocom --imap lfcrlf /dev/pts/NN'

<Mikaku>picocom is a nice serial communication program

<Mikaku>hmm, I'm testing QEMU over SSH but every time I close the connection the remote QEMU process is not killed :-/

<rickmasters>I was using screen /dev/pts/NN but there was no output

<Mikaku>change NN by the number QEMU is using

<Mikaku>(qemu) char device redirected to /dev/pts/12 (label serial0)

<Mikaku>rickmasters: you should see a message like this ^^

<rickmasters>yes, I got that but connecting to it with screen just had an empty screen with no output

<rickmasters>same thing with picocom. It says Terminal ready but then ... nothing

<Mikaku>well, if you connect picocom once the system is up then you missed all kernel messages

<Mikaku>try a simple command like 'cat /dev/fb0'

<Mikaku>you should see the kernel message "WARNING: get_device(): character device 29,0 not found."

<rickmasters>I can't type anything. But I think it doesn't matter - I managed to get debugcon output while using graphics mode

<rickmasters>The message is:

<Mikaku>ideally QEMU should have an option to be able delay the kernel boot N seconds, that will give you time to prepare 'picocom' in another terminal

<rickmasters>Page Fault at 0xbfffefc8 (writing) with error code 0x00000002 (0b10)

<rickmasters>Process './stacktest' with pid 36

<rickmasters>It repeats that about 200 times and then reboots

<Mikaku>I expected more information

<rickmasters>With the test program I provided, did you comment out the puts line?

<Mikaku>yes

<Mikaku>BTW, if you change '-nographic' by '-display none -debugcon stdio' you'll see the kernel messages in the terminal

<Mikaku>anyway, I'll test the binary when you upload it

<rickmasters>Uploaded.

<Mikaku>ok, thanks

<Mikaku>hmm ... it works well

<Mikaku># ./stacktest

<Mikaku>my size is 0

<Mikaku>filename is 0xbfffea1a

<Mikaku>statinfo is 0xbfffe9d8

<Mikaku>rickmasters: ^^

<Mikaku>no segfault, no reboots, ...

<rickmasters>In your case statinfo is not on a different stack page

<Mikaku>I see

<rickmasters>Try from source. Try adding 2560 bytes to filename and recompile

<Mikaku>ok, let me see ...

<rickmasters>Comment out the assembly to get the variable addresses first.

<Mikaku>yes

<Mikaku>hmm, with 'char filename[2560] = "stacktest";', I get:

<rickmasters>No, add 2560 to the existing value.

<Mikaku>ah

<Mikaku>sorry

<Mikaku>ok, with 'filename[6230]' I get:

<Mikaku>filename is 0xbfffe01a

<Mikaku>statinfo is 0xbfffdfd8

<Mikaku>now I'll apply this values to the assembly part and will uncomment these lines

<rickmasters>Right, looks good. Now put those values in the assembly, uncomment the assembly, recompile and retest

<Mikaku>no segfault, no reboot, I get:

<Mikaku>filename is 0xbfffe01a

<Mikaku>statinfo is 0xbfffdfd8

<Mikaku>oh, let me comment the 'puts()' line ...

<Mikaku>yes!, it segfaulted at last!

<Mikaku>:-)

<rickmasters>Yay!

<Mikaku>but no reboot, kernel just terminated the offending process

<rickmasters>Yeah, yesterday I was getting a terminate with more info, today I got something different

<Mikaku>ok, now I can work on this

<rickmasters>Not sure what changed. The original problem was causing a reboot.

<rickmasters>If anyone else wants to know what this was about, the context is here: https://github.com/mikaku/Fiwix/issues/22

<Mikaku>heh, it segfaults now because sys_newstat() finds the file called 'stacktest'

<Mikaku>if I remove or rename this file, then there is no segfault

<Mikaku>I initially called your test program as 'issue22.c', that was the reason I didn't get the segfault

<rickmasters>Yeah, it needs to get far enough to start changing statbuf

<Mikaku>now because there is your binary 'stacktest' in the same directory, it segfaults :-)

<Mikaku>my fault, sorry for wasting your time

<rickmasters>No worries. I'm just glad you got the repro.

<oriansj>stikonas: your bootstrap-seeds pull request has been merged

<stikonas>thanks

<stikonas>well, this time it was just comments changing

<stikonas>so hopefully not hard to review

<oriansj>stikonas: always a pleasure checking your work ^_^

<oriansj>and nice blog post

<stikonas>I guess at some point I should write up some changelog for stage-posix...

IRC channel logs

2023-02-02.log