error.. about os HOT 5 CLOSED

Hi Sergey,
Are you running this on Qemu via the starter pack? Is this the first time you'd fired up the starter pack, or had it been run before? I'm wondering if Qemu got shut off at the wrong time and caused some file system corruption. If this is the starter pack, does it also happen with a fresh unzip of the starter pack?

For your exploration debugging with real machines, I added an additional upload to the latest nightly build. For the build at https://www.minocacorp.com/download/nightlies/2017-09-13 I uploaded a file called minoca-bin-x86dbg.tar.gz, which contains all the debugger symbols for that build. Once you get connected to a real machine with that build installed, you can use the 'sympath' debugger command to point the debugger towards the symbols in the bin directory created by extracting that archive. Then commands like 'k' will show function names rather than raw addresses.

from os.

Yes I used the start-up package on Qemu. Updated and installed various packages, then noticed that the system often freezes, and suddenly I noticed that my debugger error

from os.

I see. Can you try doing the same thing with a clean unzip of the starter pack (into a new directory)? If we can get a set of repro steps then we can reproduce the issue on our end.

from os.

I don't understand English and even worse understand programming. Here is what I got:
opkg update
opkg install mc
mc
F10
Minoca debugger version 1.1. Protocol version 1.3.
Waiting to connect...
Connected to Minoca OS on x86
System Version 0.4.0.2414 final debug v0.4-97abb21 Jun 26 2017 19:26:52
Built on Tue Jun 27, 2017 05:26 AM.
Processor 0 alive. 0x800c7540
Boot time: 09/15/2017 09:05:35 GMT
New Device: Device, 0x808099a0
New Device: VideoConsole0, 0x8080a440
New Device: ACPI, 0x8080ad50
New Device: PNP0A03, 0x8080b130
New Device: null, 0x8080b340
New Device: PNP0103, 0x8080b5b0
New Device: zero, 0x8080b7c0
New Device: PNP0C0F, 0x8080ba30
New Device: full, 0x8080bc40
New Device: PNP0C0F#1, 0x8080beb0
New Device: urandom, 0x8080c0c0
New Device: PNP0C0F#2, 0x8080c330
New Device: tty, 0x8080c540
New Device: PNP0C0F#3, 0x8080c7b0
New Device: ACPI0007, 0x8080caf8
New Device: VEN_8086&DEV_1237, 0x8080d1a0
New Device: VEN_8086&DEV_7000, 0x80808140
New Device: VEN_8086&DEV_7010, 0x80808258
New Device: VEN_8086&DEV_7113, 0x8080f4c0
New Device: VEN_1013&DEV_00B8, 0x8080f8b8
New Device: VEN_8086&DEV_1209, 0x8080fcb0
New Device: PNP0B00, 0x80810118
New Device: PNP0303, 0x80810230
New Device: PNP0F13, 0x80810d68
New Device: PNP0700, 0x80810f78
New Device: PNP0400, 0x80811188
New Device: PNP0501, 0x80811398
New Device: PNP0501#1, 0x808115a8
New Device: Disk, 0x80811e80
New Device: RawDisk, 0x808117b8
New Device: Partition1, 0x808118d0
New Device: Partition2, 0x808119e8
New Device: Volume0, 0x80812e40
New Device: Volume1, 0x80812f68
NET: 52:54:00:12:34:56 up, Speed 100 mbps
DHCP Assignment:
Server IP: 10.0.2.2
Offered IP: 10.0.2.15
Router IP: 10.0.2.2
DNS Server IP: 10.0.2.3
Lease Time: 1 day.

*** Assertion Failure: FALSE
File: /auto/working/14332/src/os/kernel/io/pty.c, Line 737

Warning: Target timestamp for usrinput is Wed Jun 28 01:47:35 2017
but file '.\Minoca\bin/usrinput.drv' has timestamp Wed Sep 13 12:50:42 2017.
Module loaded 0x80bb2000: usrinput -> .\Minoca\bin/usrinput.drv
Warning: Target timestamp for i8042 is Wed Jun 28 01:47:40 2017
but file '.\Minoca\bin/i8042.drv' has timestamp Wed Sep 13 12:50:47 2017.
Module loaded 0x80ad6000: i8042 -> .\Minoca\bin/i8042.drv
Warning: Target timestamp for netcore is Wed Jun 28 01:48:42 2017
but file '.\Minoca\bin/netcore.drv' has timestamp Wed Sep 13 12:51:54 2017.
Module loaded 0x80b6a000: netcore -> .\Minoca\bin/netcore.drv
Warning: Target timestamp for e100 is Wed Jun 28 01:48:53 2017
but file '.\Minoca\bin/e100.drv' has timestamp Wed Sep 13 12:52:05 2017.
Module loaded 0x80aaf000: e100 -> .\Minoca\bin/e100.drv
Warning: Target timestamp for sd is Wed Jun 28 01:49:42 2017
but file '.\Minoca\bin/sd.drv' has timestamp Wed Sep 13 12:52:54 2017.
Module loaded 0x80149000: sd -> .\Minoca\bin/sd.drv
Warning: Target timestamp for usbcore is Wed Jun 28 01:47:47 2017
but file '.\Minoca\bin/usbcore.drv' has timestamp Wed Sep 13 12:50:54 2017.
Module loaded 0x80130000: usbcore -> .\Minoca\bin/usbcore.drv
Warning: Target timestamp for usbmass is Wed Jun 28 01:47:54 2017
but file '.\Minoca\bin/usbmass.drv' has timestamp Wed Sep 13 12:51:01 2017.
Module loaded 0x80141000: usbmass -> .\Minoca\bin/usbmass.drv
Warning: Target timestamp for usbhub is Wed Jun 28 01:47:51 2017
but file '.\Minoca\bin/usbhub.drv' has timestamp Wed Sep 13 12:50:58 2017.
Module loaded 0x8013f000: usbhub -> .\Minoca\bin/usbhub.drv
Warning: Target timestamp for usbcomp is Wed Jun 28 01:47:48 2017
but file '.\Minoca\bin/usbcomp.drv' has timestamp Wed Sep 13 12:50:55 2017.
Module loaded 0x8013d000: usbcomp -> .\Minoca\bin/usbcomp.drv
Warning: Target timestamp for ehci is Wed Jun 28 01:48:13 2017
but file '.\Minoca\bin/ehci.drv' has timestamp Wed Sep 13 12:51:19 2017.
Module loaded 0x80128000: ehci -> .\Minoca\bin/ehci.drv
Warning: Target timestamp for pci is Wed Jun 28 01:49:26 2017
but file '.\Minoca\bin/pci.drv' has timestamp Wed Sep 13 12:52:38 2017.
Module loaded 0x80120000: pci -> .\Minoca\bin/pci.drv
Warning: Target timestamp for ata is Wed Jun 28 01:47:19 2017
but file '.\Minoca\bin/ata.drv' has timestamp Wed Sep 13 12:50:26 2017.
Module loaded 0x8011a000: ata -> .\Minoca\bin/ata.drv
Warning: Target timestamp for ahci is Wed Jun 28 01:47:15 2017
but file '.\Minoca\bin/ahci.drv' has timestamp Wed Sep 13 12:50:22 2017.
Module loaded 0x80114000: ahci -> .\Minoca\bin/ahci.drv
Warning: Target timestamp for videocon is Wed Jun 28 01:50:07 2017
but file '.\Minoca\bin/videocon.drv' has timestamp Wed Sep 13 12:53:20 2017.
Module loaded 0x8010c000: videocon -> .\Minoca\bin/videocon.drv
Warning: Target timestamp for special is Wed Jun 28 01:50:02 2017
but file '.\Minoca\bin/special.drv' has timestamp Wed Sep 13 12:53:15 2017.
Module loaded 0x80109000: special -> .\Minoca\bin/special.drv
Warning: Target timestamp for part is Wed Jun 28 01:47:16 2017
but file '.\Minoca\bin/part.drv' has timestamp Wed Sep 13 12:50:23 2017.
Module loaded 0x80104000: part -> .\Minoca\bin/part.drv
Warning: Target timestamp for null is Wed Jun 28 01:49:21 2017
but file '.\Minoca\bin/null.drv' has timestamp Wed Sep 13 12:52:33 2017.
Module loaded 0x80102000: null -> .\Minoca\bin/null.drv
Warning: Target timestamp for fat is Wed Jun 28 01:47:29 2017
but file '.\Minoca\bin/fat.drv' has timestamp Wed Sep 13 12:50:35 2017.
Module loaded 0x800f2000: fat -> .\Minoca\bin/fat.drv
Warning: Target timestamp for acpi is Wed Jun 28 01:47:12 2017
but file '.\Minoca\bin/acpi.drv' has timestamp Wed Sep 13 12:50:19 2017.
Module loaded 0x800cf000: acpi -> .\Minoca\bin/acpi.drv
Warning: Target timestamp for kernel is Wed Jun 28 01:39:06 2017
but file '.\Minoca\bin/kernel' has timestamp Wed Sep 13 12:41:42 2017.
Module loaded 0x80001000: kernel -> .\Minoca\bin/kernel
kernel+0xd05c:
8000e05c ret ; c3
kd>k
Frame RetAddr Call Site
80e13ca0 8001c707 kernel+0xd05c
80e13cc0 80064811 kernel!RtlRaiseAssertion+0x33
80e13cf0 80064bcc kernel!IoSetTerminalSettings+0xba
80e13df0 80050fa6 kernel!IopTerminalUserControl+0x127
80e13e20 8006eb8e kernel!IoUserControl+0x63
80e13e70 8003bd27 kernel!IoSysUserControl+0x96
80e13fa4 800965ec kernel!KeSystemCallHandler+0xf4
80e13fb8 777d5307 kernel+0x955ec
7fffec78 7735be46 0x777d5307
7fffecd8 77380cd6 0x7735be46
7fffecf8 777506e3 0x77380cd6
7fffed28 7774cbc8 0x777506e3
7fffed78 0808e84a 0x7774cbc8
7fffed88 0808e6d2 0x0808e84a
7fffed98 0804ec58 0x0808e6d2
7fffedd8 080eb0ad 0x0804ec58
7fffee14 777d6f2b 0x080eb0ad
7fffee64 00000000 0x777d6f2b

from os.

Hi Sergey,
Thanks for that, and no problem about the English. I haven't played much with mc. With your steps I was able to see this latest assert on my end too. The assert you hit above is different from the first one you showed. It should be safe to hit 'g' to through this assert. I will make a change to fix it. I also noticed mc isn't rendering very well in our console, so I will take a look at that and see if we're missing some terminal emulation. It looks fine over SSH though.

If you do manage to reproduce the first issue feel free to send me steps. I suspect that Qemu got closed while there was still dirty data in the cache. We usually use 'reboot -s' to shutdown cleanly.

from os.