RISC OS Open: Forum: LanManFS debugging

Aug 5, 2018 9:22am

I have been trying to debug “LanMan in use” issues with Colin’s LanMan_timout debug version of the module but instead run in aborts instea of the expected issue.

Basically, I plays MP3s stored on a USB key connected to my router and at some random point I get an abort. I have collected the info in Report

File ReportList02 contains the !Reporter file, ShowRegs a register dump of the first abort (somewhere in the the SharedCLibrary), ShowRegs2 a later abort with LanManFS itself. As Jeffrey mentionned the possibility to collect abort stack dumps I retried today, which gives the additional execdump file (though no reporter file since my machine stopped responding before I saved the report).

Aug 5, 2018 9:28am

André Timmermans (100) 655 posts

There are also other ways to cause issues with with LanManFS like manipulating archives with SparkFS (I created a new archive, add a folder with one of my project to it, then attempted to delete files from the “o” subfolder and it reported errors as if the share didn’t exist) or performing transfers in parallel in both directions).

Aug 5, 2018 10:54am

Colin (478) 2433 posts

The showregs2 file is the same bug as Will reported and occurs in debug code (DumpBuffer) which is only used in the debug version for tracing reason codes which are not used in the non-debug version of the module – ie the non-debug version ignores these reason codes. LanManFS_timeout2.zip is a debug version which bypasses the tracing of these reason codes so should stop this particular abort.

I haven’t had chance to look at your other reports.

Aug 5, 2018 11:11am

Colin (478) 2433 posts

I created a new archive, add a folder with one of my project to it, then attempted to delete files from the “o” subfolder and it reported errors as if the share didn’t exist

I can’t repeat that at the moment – but then I haven’t had much luck reproducing any problems here. Is this a problem with the with the timeout version? or was it something you noticed before? In the original version of LanManFS you could have problems with files/dirs that are inside a directory which has characters that need translating. I thought I’d fixed that.

Aug 5, 2018 7:37pm

André Timmermans (100) 655 posts

I have now tested with the timeout2 version.
Crash with basically the same excdump stack.
Reporter and excdump files in Report2.zip

All these issues are old ones that I reported here in the past already and I just thought to use the debug version to see if it could highlight the problems. Well, I was not expecting aborts instead of the “LanManFS in use” errors which i get with the normal 2.61 version.

Aug 5, 2018 7:57pm

André Timmermans (100) 655 posts

For the archive manipulation issue, I have no crash but a “File sharing violation” issue. See Report3.zip

Aug 6, 2018 9:42pm

Colin (478) 2433 posts

Can you repeat the bugs easily? If so does WireSalmon work for you on a Pi3. I’ve only just got it working on my ArmX6 as it needed alignment exceptions turned off before it would work – it may be the same on a Pi3.

If you can get it working and can reproduce the problem easily could you run wiresalmon, start a capture, do what you need to do to reproduce the bug then stop the capture. The captures may be quite large if you leave it recording for a long time.

Can you then send the captures to me – or make them available on your web site.

The Access Violation error is an error returned by the server so hopefully the wiresalmon output will show if something looks wrong.

Thanks.

Aug 8, 2018 6:29pm

André Timmermans (100) 655 posts

I will give WireSalmon a try tomorrow.

Aug 11, 2018 5:15pm

André Timmermans (100) 655 posts

Sorry, but WireSalmon doesn’t work on the PI3.

Aug 12, 2018 10:02am

Colin (478) 2433 posts

It doesn’t matter I think I’ve found the problem – see other thread. Could you try the LanManFS_02 and see if it crashes – I couldn’t replicate any crashes.

Aug 14, 2018 7:42pm

André Timmermans (100) 655 posts

I tried the LanManFS_04 version, it made no difference, either to the archive manupulation issue or the crash while playing music from files stored on the NAS.

I noticed one thing thought with the dump generated for the music playing issue. This a little part of the dump:

According to the Socket_Recv doc:
fa207b7c : 44693c77 : | R1 |
fa207b80 : 000073c9 : | R2 |
R1 & R2 should be the buffer address and size

while the crash occurs in the Internet module for instruction STRGEB R3,[R0,#-1]! with R0 = 4469421f

R0 clearly fits within the buffer limits so either the buffer size provided by LanManFS is incorrect or this buffer was maybe deallocated.

Aug 14, 2018 10:02pm

Colin (478) 2433 posts

Changes in 04 were unlikely to fix your crashes.

How frequent are these crashes? I’ve done a bit of testing streaming 24bit flacs with my IsocPlayer program over LanManFS without problems so far. Are you sure the bug isn’t in your program? The receive buffer location and the len comes directly from the OS_GBPB call as far as I can tell and are just passed through to the socket recv function.

Aug 17, 2018 7:46am

André Timmermans (100) 655 posts

Definitely a problem in LanManFS. I retried today and since it didn’t crash the system directly I had time to collect some info:

The caller is DiskSample which for the call tries to fill in dynamic area “DiskSample (Input1)” located at 52fa6000 with data header size (&40) and circular buffer size (&40000), free offset is &10000 and start of fille part at offset (&20084).
It attempts to fill some of the free area, that is from 52fb6040 to 52fc6040 (&10000 bytes).

This can be see in the stack trace register list of the dump during the transition from FileSwitch to LanManFs. At some point within LanManFs the stack starts refering to 530e6040 (which is somewhere in another dina;yc area) and the Internet module crashes while trying to write to 530e7af8.

As you can see the is a jump of &120000 bytes in the buffer adress. I should have added the dump to the post but I did not take a copy of the dump, had to reboot in order to be able to use Netsurf and of course the dump got overwritten due to another crash during the shutdown. I will have to reproduce the problem again.

Aug 17, 2018 8:07am

André Timmermans (100) 655 posts

Test with your LanManFS_05.

Trying to fill from 48bc5040 to 48bd5040 (+&1000).
At some post references to 48ce5040 appear and it crashes on address 48ce722c.

Error block: 80000002 Internal error: abort on data transfer at &FC177A78
R0 = 48ce722c
R1 = 2011a998
R2 = 00000380
R3 = 03d95cc3
R4 = 38bf657c
R5 = 000003a0
R6 = fa207ac0
R7 = 2011a608
R8 = 000003a0
R9 = 00000000
R10 = fa20021c
R11 = fa207a48
R12 = bfd9b8a1
R13 = fa207a20
R14 = 29aecb29
R15 = fc177a78
CPSR = 20000113
R13_usr = 000906a0
R14_usr = 0006429c
R13_svc = fa207a20
R14_svc = 29aecb29
SPSR_svc = 40000193
R13_irq = fa102000
R14_irq = 60000113
SPSR_irq = 60000113
R13_abt = fa301fa8
R14_abt = fc177a78
SPSR_abt = 20000113
R13_und = fa402000
R14_und = 0004d074
SPSR_und = 60000110
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 3 = fa200000, 00008000, 00008000
OSMem16: 4 = fa300000, 00002000, 00002000
OSMem16: 5 = fa400000, 00002000, 00002000
Memory: fa100000 – fa102000
Memory: fa200000 – fa208000
Memory: fa300000 – fa302000
Memory: fa400000 – fa402000
Memory: ffff0108 – ffff010c
OSRSI6: 69 = ffff0108

R15 = fc177a78 = SharedCLibrary +c9bc = memmove +28c
R14_svc = 29aecb29 = Module area +9aecb29

R14_usr = 0006429c = +5c29c in application memory = Task_PollIdle +68
Function call to fc19cd08 = SharedCLibrary +31c4c = _kernel_swi +0

USR stack:
000906a0 : 000906c0 : – R2
000906a4 : 0008bcdc : | R4
000906a8 : 00000002 : | R5
000906ac : 00036f94 : | R6
000906b0 : 00000000 : | R7
000906b4 : 0008ef78 : | R8
000906b8 : 0008f1a8 : | R9
000906bc : 0006429c : | R14: 0006429c (ASM call to fc19cd08)
: : | 0006429c = +5c29c in application memory
: : | = Task_PollIdle +68
: : | fc19cd08 = SharedCLibrary +31c4c
: : | = kernel_swi +0
000906c0 : 00000000 :
000906c4 : 0008bcdc :
000906c8 : 00036f94 :
000906cc : 00000000 :
000906d0 : 00000000 :
000906d4 : 00000000 :
000906d8 : 00000001 :
000906dc : 00000001 :
000906e0 : 00090724 :
000906e4 : 0008c56c :
000906e8 : 00000000 : – R0
000906ec : 00000002 : | R1
000906f0 : 0008c124 : | R4
000906f4 : 00000001 : | R5
000906f8 : 00090cfc : | R6
000906fc : 00090780 : | R11
00090700 : 0009070c : | R12
00090704 : 000641d4 : | R14: 000641d4
: : | = +5c1d4 in application memory
: : | = Task_MainLoop +5c
00090708 : 00064240 : | APCS function: 00064238
: : | = +5c238 in application memory
: : | = Task_PollIdle +4
0009070c : 00000000 : |
00090710 : 0008c124 : |
00090714 : 00000001 : |
00090718 : 00090cfc : |
0009071c : 00000000 : |
00090720 : 0008ef78 : |
00090724 : 0008f1a8 : |
00090728 : 0008fa60 : |
0009072c : 00090780 : |
00090730 : 0009070c : |
00090734 : 000641bc : | – fc16c19c return to 000641bc?
: : | | fc16c19c = SharedCLibrary +10e0
: : | | = setjmp +0
: : | | 000641bc = +5c1bc in application memory
: : | | = Task_MainLoop +44
00090738 : 00000000 : |
0009073c : 00000000 : |
00090740 : 00000000 : |
00090744 : 00000000 : |
00090748 : 00000000 : |
0009074c : 00000000 : |
00090750 : 00000000 : |
00090754 : 00000000 : |
00090758 : 00000000 : |
0009075c : 00000000 : |
00090760 : 00000000 : |
00090764 : 00000000 : |
00090768 : 00000000 : | R0
0009076c : 00000002 : | R1
00090770 : 00085888 : | R4
00090774 : 000907a4 : | R11
00090778 : 00090784 : | R12
0009077c : 0003f87c : | R14: 0003f87c
: : | = +3787c in application memory
: : | = main +98
00090780 : 00064184 : | APCS function: 0006417c
: : | = +5c17c in application memory
: : | = TaskMainLoop +4
00090784 : 00000001 : | R0
00090788 : 00090cfc : | R1
0009078c : 0009082d : | R4
00090790 : ffffffff : | R5
00090794 : 00000000 : | R6
00090798 : 00090800 : | R11
0009079c : 000907a8 : | R12
000907a0 : fc16f154 : | R14: fc16f154
: : | = SharedCLibrary +4098
: : | = _main +404
000907a4 : 0003f7f0 : | APCS function: 0003f7e8
: : | = +377e8 in application memory
: : | = main +4
000907a8 : 20000000 : |
000907ac : ffffffff : |
000907b0 : 00000001 : |
000907b4 : 00000000 : |
000907b8 : 00000000 : |
000907bc : 00000000 : |
000907c0 : 00000014 : | – R9
000907c4 : fc16ed00 : | | R14: fc16ed00 (ASM call to fc19cd48)
: : | | fc16ed00 = SharedCLibrary +3c44
: : | | = _armsys_lib_init +48
: : | | fc19cd48 = SharedCLibrary +31c8c
: : | | = kernel_osbyte +0
000907c8 : 0008ecec : |
000907cc : 0008ed3c : |
000907d0 : 03ef0a10 : |
000907d4 : 00090818 : | R0
000907d8 : 0003f7e4 : | R1
000907dc : 00090818 : | R4
000907e0 : 00084c68 : | R5
000907e4 : 00084c68 : | R6
000907e8 : 00000028 : | R7
000907ec : 0008ead4 : | R8
000907f0 : 0008e9cc : | R9
000907f4 : 00090814 : | R11
000907f8 : 00090804 : | R12
000907fc : 0007bf50 : | R14: 0007bf50
: : | = +73f50 in application memory
: : | = throw_NewWListKeySelect +e8
00090800 : fc16ed5c : | APCS function: fc16ed54
: : | = SharedCLibrary +3c98
: : | = main +4
00090804 : 0007bf1c : | R4 – Return to 0007bf1c?
: : | | = +73f1c in application memory
: : | | = throw_NewWListKeySelect +b4
00090808 : 00000000 : | R11
0009080c : 00090818 : | R12
00090810 : fc19bdcc : | R14: fc19bdcc
: : | = SharedCLibrary +30d10
: : | = kernel_CallInitProcs +48
00090814 : 0007bf28 : | APCS function: 0007bf20
: : | = +73f20 in application memory
: : | = throw_NewWListKeySelect +b8
00090818 : 69676944 :
0009081c : 436c6174 :
00090820 : 69443a44 :
00090824 : 61746967 :
00090828 : 2044436c :
0009082c : 69676900 :
00090830 : 00090830 :
00090834 : 00d4ffe5 :
00090838 : 00000000 :
0009083c : 0000027c :
00090840 : 00d4ffe5 :
00090844 : 03ef0a10 :
00090848 : 00000000 :
0009084c : 00d4ffe5 :
00090850 : 00d4ffe5 :
00090854 : 00d4ffe5 :
00090858 : 00d4ffe5 :
0009085c : 00d4ffe5 :
00090860 : 00d4ffe5 :
00090864 : 00d4ffe5 :
00090868 : 00d4ffe5 :
0009086c : 00d4ffe5 :
00090870 : 00d4ffe5 :
00090874 : 00d4ffe5 :
00090878 : 00d4ffe5 :
0009087c : 00d4ffe5 :
00090880 : 00d4ffe5 :
00090884 : 00d4ffe5 :
00090888 : 00d4ffe5 :
0009088c : 00d4ffe5 :
00090890 : 00d4ffe5 :
00090894 : 00d4ffe5 :
00090898 : 00d4ffe5 :
0009089c : 00d4ffe5 :
000908a0 : 00d4ffe5 :
000908a4 : 00d4ffe5 :
000908a8 : 00d4ffe5 :
000908ac : 00d4ffe5 :
000908b0 : 00d4ffe5 :
000908b4 : 00d4ffe5 :
000908b8 : 00d4ffe5 :
000908bc : 00d4ffe5 :
000908c0 : 00d4ffe5 :
000908c4 : 00d4ffe5 :
000908c8 : 00d4ffe5 :
000908cc : 00d4ffe5 :
000908d0 : 00d4ffe5 :
000908d4 : 00d4ffe5 :
000908d8 : 00d4ffe5 :
000908dc : 00d4ffe5 :
000908e0 : 00d4ffe5 :
000908e4 : 00d4ffe5 :
000908e8 : 00d4ffe5 :
000908ec : 00d4ffe5 :
000908f0 : 00d4ffe5 :
000908f4 : 00d4ffe5 :
000908f8 : 00d4ffe5 :
000908fc : 00d4ffe5 :
00090900 : 00d4ffe5 :
00090904 : 00d4ffe5 :
00090908 : 00d4ffe5 :
0009090c : 00d4ffe5 :
00090910 : 00d4ffe5 :
00090914 : 00d4ffe5 :
00090918 : 00d4ffe5 :
0009091c : 00d4ffe5 :
00090920 : 00d4ffe5 :
00090924 : 00d4ffe5 :
00090928 : 00d4ffe5 :
0009092c : 00d4ffe5 :
00090930 : 00d4ffe5 :
00090934 : 00d4ffe5 :
00090938 : 00d4ffe5 :
0009093c : 00d4ffe5 :
00090940 : 00d4ffe5 :
00090944 : 00d4ffe5 :
00090948 : 00d4ffe5 :
0009094c : 00d4ffe5 :
00090950 : 00d4ffe5 :
00090954 : 00d4ffe5 :
00090958 : 00d4ffe5 :
0009095c : 00d4ffe5 :
00090960 : 00d4ffe5 :
00090964 : 00d4ffe5 :
00090968 : 00d4ffe5 :
0009096c : 00d4ffe5 :
00090970 : 00d4ffe5 :
00090974 : 00d4ffe5 :
00090978 : 00d4ffe5 :
0009097c : 00d4ffe5 :
00090980 : 00d4ffe5 :
00090984 : 00d4ffe5 :
00090988 : 00d4ffe5 :
0009098c : 00d4ffe5 :
00090990 : 00d4ffe5 :
00090994 : 00d4ffe5 :
00090998 : 00d4ffe5 :
0009099c : 00d4ffe5 :
000909a0 : 00d4ffe5 :
000909a4 : 00d4ffe5 :
000909a8 : 00d4ffe5 :
000909ac : 00d4ffe5 :
000909b0 : 00d4ffe5 :
000909b4 : 00d4ffe5 :
000909b8 : 00d4ffe5 :
000909bc : 00d4ffe5 :
000909c0 : 00d4ffe5 :
000909c4 : 00d4ffe5 :
000909c8 : 00d4ffe5 :
000909cc : 00d4ffe5 :
000909d0 : 00d4ffe5 :
000909d4 : 00d4ffe5 :
000909d8 : 00d4ffe5 :
000909dc : 00d4ffe5 :
000909e0 : 00d4ffe5 :
000909e4 : 00d4ffe5 :
000909e8 : 00d4ffe5 :
000909ec : 00d4ffe5 :
000909f0 : 00d4ffe5 :
000909f4 : 00d4ffe5 :
000909f8 : 00d4ffe5 :
000909fc : 00d4ffe5 :
00090a00 : 00d4ffe5 :
00090a04 : 00d4ffe5 :
00090a08 : 00d4ffe5 :
00090a0c : 00d4ffe5 :
00090a10 : 00d4ffe5 :
00090a14 : 00d4ffe5 :
00090a18 : 00d4ffe5 :
00090a1c : 00d4ffe5 :
00090a20 : 00d4ffe5 :
00090a24 : 00d4ffe5 :
00090a28 : 00d4ffe5 :
00090a2c : 00d4ffe5 :
00090a30 : 00d4ffe5 :
00090a34 : 00d4ffe5 :
00090a38 : 00d4ffe5 :
00090a3c : 00d4ffe5 :
00090a40 : 00d4ffe5 :
00090a44 : 00d4ffe5 :
00090a48 : fc16d1c0 : – R14: fc16d1c0 (ASM call to fc19d6d4)
: : | fc16d1c0 = SharedCLibrary +2104
: : | = _primitive_alloc +28
: : | fc19d6d4 = SharedCLibrary +32618
: : | = AcquireMutex +0
00090a4c : 00000000 :
00090a50 : 00000000 :
00090a54 : 00002000 :
00090a58 : 00000400 :
00090a5c : 00001000 : – R4
00090a60 : 0008e9cc : | R5
00090a64 : 760690ff : | R6
00090a68 : 00000230 : | R7
00090a6c : 00000155 : | R8
00090a70 : 00000001 : | R9
00090a74 : 00090a94 : | R11
00090a78 : 00090a84 : | R12
00090a7c : fc16d688 : | R14: fc16d688
: : | = SharedCLibrary +25cc
: : | = malloc +30
00090a80 : fc16d1a4 : | APCS function: fc16d19c
: : | = SharedCLibrary +20e0
: : | = _primitive_alloc +4
00090a84 : 00113160 : | R4
00090a88 : 00000000 : | R11
00090a8c : 00090a98 : | R12
00090a90 : fc19d618 : | R14: fc19d618
: : | = SharedCLibrary +3255c
: : | = _kernel_StkOvfGetNewChunk +7c
00090a94 : fc16d664 : | APCS function: fc16d65c
: : | = SharedCLibrary +25a0
: : | = malloc +4
00090a98 : 00001000 :
00090a9c : fc16d6b8 :

End of dump

Aug 17, 2018 8:34am

André Timmermans (100) 655 posts

Note that since I notticde that the “Pre-load next track” option was active in DigitalCD, I disabled it to ensure that I only access I file at a time but still manage to produce the dump, though heve address 44683040 seems to become 44693063, i.e a change by +&10023 this time.

Aug 17, 2018 9:17am

André Timmermans (100) 655 posts

I have been looking at the sources of SMB_Read and noticed:

SMB_TxWords⁰ = fid; SMB_TxWords¹ = min(len_left, MAX_RX_BLOCK_SIZE); SMB_TxWords² = offset & 0xFFFF; SMB_TxWords³ = (offset >> 16 ); SMB_TxWords⁴ = (len_left);

Is the value of SMB_TxWords⁴ normal, should it not be “SMB_TxWords⁴ = SMB_TxWords¹;” ?

Aug 17, 2018 11:35am

Colin (478) 2433 posts

That’s not where the bug is, it’s in the loop containing SMB_ReadRaw.

You have these functions

/* GetBytes  =================================================== */

_kernel_oserror *fsentry_getbytes( int *R )
{
  int fid = R[1]-1;

  if ( fid < 0 || fid >= MAXFILES || FileTbl[fid].Free )
    return MsgError(EBADPARAM);

  return MsgError( SMB_Read (FileTbl[fid].SMB_FH,
                      R[4],      /* Offset */
                      R[3],      /* Length */
             (BYTE *)(R[2]),     /* Where */
                      NULL ) );

}

err_t SMB_Read ( int FH, uint offset, uint len, BYTE *where,
    uint *pOutLen )
{

static uint SMB_ReadRaw ( hSHARE hS,
                     int fid, uint offset, uint len, BYTE *where )
{

static bool ReadData ( int sid, BYTE *where, int len, uint timeout, int flags )
{

And this debug output

: : | = SMB_ReadRaw +8
fa207c7c : 20146fec : | 
fa207c80 : 00001115 : | 
fa207c84 : 00440000 : | 
fa207c88 : 00008000 : | 
fa207c8c : 48ce5040 : | 
fa207c90 : 00000000 : | 
fa207c94 : 00000009 : | 
fa207c98 : 20498fb4 : | 
fa207c9c : 0000000a : | 
fa207ca0 : 00000002 : | 
fa207ca4 : 2434c48c : | R4
fa207ca8 : fff60344 : | R5
fa207cac : 000001ff : | R6
fa207cb0 : fff60344 : | R7
fa207cb4 : 0000002c : | R8
fa207cb8 : 300ef99c : | R9
fa207cbc : fa207cf0 : | R11
fa207cc0 : fa207cdc : | R12
fa207cc4 : 2060b540 : | R14: 2060b540
: : | = LanManFS +1242c
: : | = fsentry_getbytes +68
fa207cc8 : 205fde48 : | APCS function: 205fde40
: : | = LanManFS +4d2c
: : | = SMB_Read +8
fa207ccc : 00001115 : | 
fa207cd0 : 00320000 : | 
fa207cd4 : 00010000 : | 
fa207cd8 : 48bc5040 : | 
fa207cdc : 00000000 : | 
fa207ce0 : fa207cf4 : | R0
fa207ce4 : 00000000 : | R11
fa207ce8 : fa207cf4 : | R12
fa207cec : 2060ef08 : | R14: 2060ef08
: : | = LanManFS +15df4
fa207cf0 : 2060b4e4 : | APCS function: 2060b4dc
: : | = LanManFS +123c8
: : | = fsentrygetbytes +4
fa207cf4 : 48bd5040 : | R0 \ CMHG veneer kernel_swi_regs?
fa207cf8 : 00000002 : | R1 |
fa207cfc : 48bc5040 : | R2 |
fa207d00 : 00010000 : | R3 |
fa207d04 : 00320000 : | R4 |
fa207d08 : 00519531 : | R5 |
fa207d0c : 000001ff : | R6 |
fa207d10 : fff60344 : | R7 |
fa207d14 : 300efd38 : | R8 |
fa207d18 : fa207dec : | R9 /
fa207d1c : 30003694 :
fa207d20 : fc054970 : – fc054bac return to fc054970?
: : | fc054bac = FileSwitch +cb14

So you are calling OS_GBPB with a buffer at 48bc5040 and len 00010000. SMB_ReadRaw from the loop in SMB_Read is being called from address 48ce5040. As SMB_readraw is done in 0×8000 byte chunks it should not be called with an address >= 48bd5040.

Aug 17, 2018 12:07pm

André Timmermans (100) 655 posts

Indeed my remark hasn’t anything to do with the DMB_ReadRaw calls from the stack, just something curious I noticed.

Looking at the differences between content of fa207c80-8c and of of fa207ccc-d8, it looks that the SMB_ReadRaw loop in the SMB_Read code has increase both “where” and “offest” by &12000 while “len_left” was decreased by &8000. I can think of a way for the loop to continue past its limit if SMB_ReadRaw signals having returned more bytes than was requested: len_left becomes negative but since it has type “uint” it is seen as a large positive number and the loops continue. It we assume &8000 is the value of “len” in SMB_ReadRaw after its limitation by “if (len>RDRAW_BLOCK_SIZE) len=RDRAW_BLOCK_SIZE;” it would make sense.

Aug 17, 2018 12:25pm

Colin (478) 2433 posts

SMB_TxWords[4] is just an estimate of remaining bytes to read. SMB_TxWords[1] is the number of bytes requested.

Yes it looks like SMB_ReadRaw is returning a value in n_read > len_left so that len_left -= n_read is a huge value.

Would you say the crash happens at the end of the music?

Aug 17, 2018 1:06pm

Colin (478) 2433 posts

Would you like to try LanManFS_Test_06a.zip I’ve just added some debug output to see if n_read is ever > len_left and fail gracefully if it does. Hopefully it will show n_read > len_left.

Aug 17, 2018 2:07pm

André Timmermans (100) 655 posts

Not quite according to the dumps offset (which I assume corresponds to the position in the file) was 320000 and 4F0000 so even with 10000 of length to fill it doesn’t reach the sizes of the 3 first files in my playlist which have a size of 50xxxx.

I have been trying a new crash just to give it another but I am now at the 16th file in the playlist and it still didn’t crash while it usually crash within the 2 first files.

Aug 18, 2018 2:54pm

Colin (478) 2433 posts

Could you try this LanManFS_06b.zip

It turns out that SMB_ReadRaw and SMB_WriteRaw didn’t have a re-entrancy guard on them whereas all other commands go through Do_SMB which does have a re-entrancy guard. If you connected to a windows server SMB_ReadRaw and SMB_WriteRaw aren’t used so re-entrancy is checked for when read/writeraw isn’t used. So I’ve added the re-entrancy guard to these functions. It may explain an intermittant problem.

Note: It is the re-entrancy guard which triggers ‘LanMan in use’ errors you said you had earlier.

Aug 19, 2018 2:29pm

André Timmermans (100) 655 posts

I tested version 06b, it had no effect, still the same crash.

Aug 20, 2018 9:26am

Colin (478) 2433 posts

I’ve found the problem. The crash is made worse because the anti-idle is more often – it’s a re-entrancy issue. stopping the anti-idle happening stops the crash. The rom version also crashes while playing but it takes between 10 and 18 mins into the recording for it to happen. Fixing that crash is easy enough but it has highlighted a bigger problem and that is while playing via DigitalCD – the problem isn’t specific to DigitalCD it just makes the problem more apparent – doing anything else with lanmanfs will cause problems.

I presume that you are filling the DigitalCD buffer from a callback?

Aug 20, 2018 9:39am

Chris Johnson (125) 825 posts

This is interesting. I was using DigitalCD yesterday, playing some mp3s from the NAS via LanManFS. I had several crashes (real crashes needing a big finger on the reset button). In I think two of the crashes I was looking at filer windows on the NAS at the time. Reverting to playing files stored on a local drive gave no problems. This was on a Titanium, but I have always found LanManFS rather flaky for music streaming, probably more so than LanMan98.

I’ll certainly give any test versions you produce a good go.

LanManFS debugging

Reply

Search forums

Social

ROOL Store

Donate! Why?

RISC OS IPR

Description

Voices

Options