Re: Unpicking require

[Gavin Wraith <gavin@...>]

On 2021-11-25 13:07, Roberto Ierusalimschy wrote:

> When 'require' fails, its error message contains the names of all
> files it tried to open. If there are no bugs there, these names should
> be exactly the ones given to 'fopen':
>
> > require 'XX.YY'
> stdin:1: module 'XX.YY' not found:
> 	no field package.preload['XX.YY']
> 	no file '/usr/local/share/lua/5.4/XX/YY.lua'
> 	no file '/usr/local/share/lua/5.4/XX/YY/init.lua'
>         [...]
>
> Can't you use that to check whether your configuration is correct?

Thanks. I had just got this issue sorted. But I have another. Dynamic 
loading of C modules causes a segmentation fault after the loaded code 
has run.

This:

  local path, cpath in package
  print (path, cpath)
  local x = require "riscos"
  print (x.version)

produces this:

rlua:lib.?,?    rlua:solib.?/so,?/so
RiscLua 544VFP-A

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x4920c (Main Thread)
  ( 8d87f34) pc: 560c7e78 lr: 560c8358 sp:  8d87f38  __write_backtrace()
  ( 8d87fa0) pc: 560c808c lr: 560c9ef0 sp:  8d87fa4  
__unixlib_raise_signal()
  ( 8d87fb0) pc: 560c9dd8 lr: 560d5e88 sp:  8d86c84  __h_cback()

  Register dump at 08d87fb4:

    a1:    4c07c a2: 722e6269 a3:     186c a4:        0
    v1:    4c07c v2: 722e6269 v3:    3d3a4 v4:    76588
    v5: 560d5e44 v6:    3cab4 sl:  8d86208 fp:  8d86c9c
    ip:  8d86ca0 sp:  8d86c84 lr: 560d5e88 pc: 560d4dd0
    cpsr: 20000110

  560d4dbc : ..Qã : e3510000 : CMP     R1,#0
  560d4dc0 : .@ á : e1a04000 : MOV     R4,R0
  560d4dc4 : p¨.. : 091ba870 : LDMEQDB R11,{R4-R6,R11,R13,PC}
  560d4dc8 : ...å : e5110004 : LDR     R0,[R1,#-4]
  560d4dcc : .À”å : e594c000 : LDR     R12,[R4,#0]
  560d4dd0 : .0Àã : e3c03003 : BIC     R3,R0,#3
  560d4dd4 : ..Sá : e153000c : CMP     R3,R12
  560d4dd8 : . Aâ : e2412008 : SUB     R2,R1,#8
  560d4ddc : ,..š : 9a00002c : BLS     &560D4E94

  ( 8d86c9c) pc: 560d4db4 lr: 560d5e88 sp:  8d86ca0  free_unlocked()
  ( 8d86cb4) pc: 560d5e50 lr: 56021010 sp:  8d86cb8  __free()
  ( 8d86ce0) pc: 56020e58 lr: 560216a0 sp:  8d86ce4  do_dlclose()
  ( 8d86cf0) pc: 56021690 lr:    32194 sp:  8d86cf4  _dlclose()
  ( 8d86d0c) pc:    32148 lr:    1217c sp:  8d86d10  gctm()
  ( 8d86d40) pc:    11fb8 lr:    12424 sp:  8d86d44  luaD_precall()
  ( 8d86d5c) pc:    123f0 lr:    14384 sp:  8d86d60  luaD_callnoyield()
  ( 8d86d6c) pc:    1436c lr:    11094 sp:  8d86d70  dothecall()
  ( 8d86e08) pc:    1103c lr:    127f0 sp:  8d86e0c  
luaD_rawrunprotected()
  ( 8d86e30) pc:    127c4 lr:    14308 sp:  8d86e34  luaD_pcall()
  ( 8d86e68) pc:    141ec lr:    15eec sp:  8d86e6c  GCTM()
  ( 8d86e88) pc:    15eb0 lr:    1b9b8 sp:  8d86e8c  
luaC_freeallobjects()
  ( 8d86ea0) pc:    1b98c lr:    1bfe8 sp:  8d86ea4  close_state()
  ( 8d86eb0) pc:    1bfd4 lr:     b178 sp:  8d86eb4  lua_close()
  ( 8d86ed4) pc:     b0e4 lr: 560dec90 sp:  8d86ed8  main()

It did not happen with Lua 5.4.3. Nothing else changed.