MantisBT - Issues

0000915: SIGSEGV in yyparse/read_jump_offset/get_bc_offset when compiling large LPC with foreach+continue

Thu, 26 Mar 2026 20:19:03 +0000

Hi team,
I was running into a frequent crash when the main living object was compiling, so I used my AI workflow to reproduce it and document. This actual crash is a bit over my head.
Note that this driver has a few custom add-ins but as far as can be told, they aren't affecting this crash.

The reproduce example file is atrocious and maybe unnecessary but it's just being used to demonstrate the issue.

Environment

LDMud: 3.6.6 (custom fork)
Platform: Ubuntu 22.04, x86_64
Core handling: apport (/var/lib/apport/coredump)
Summary
Compiling a large LPC file containing repeated foreach (...) { ... continue; ... } patterns causes a deterministic driver segfault during compile time.

Observed Behavior

Driver crashes with SIGSEGV
Stack shows:
get_bc_offset()
read_jump_offset()
yyparse() (prolang.y, continue/jump patching path)
Crash happens while compiling LPC (not runtime execution).
Expected Behavior
Compiler should either compile successfully or emit a compile error, never segfault.

0000720: Support DTLS (Datagram Transport Layer Security)

Tue, 23 Dec 2025 00:06:17 +0000

Datagram Transport Layer Security (DTLS) protocol provides communications privacy for datagram protocols. It is based on the stream-oriented TLS protocol and is intended to provide similar security guarantees.
Since we support TLS for TCP connections, I think we should also support DTLS. This may also open up the possibility to encrypt Intermud traffic transparently at some point in the future.

Unfortunately, DTLS is not widely supported yet. OpenSSL has support for it, but no documentation at all. GnuTLS does not support it (yet?).
Until that changes or I have much more time to look into the code of OpenSSL (*shudder*), this issue serves just as reminder for the future...

0000908: add_action with some efun operator closure args produces segfault

Mon, 07 Jul 2025 22:30:58 +0000

I was writing an object that used `add_action` with a closure argument and noticed I could reliably segfault 3.6.7 (also 3.6.6 and 3.6.5) if the initial closure arg to 'efun::add_action' was given a particular efun operator closure as argument, instead of the intended lfun (e.g. because the lfun was accidentally omitted, or had the wrong name).

The choice of efun closure appears to matter. Using a normal efun closure like #'write, or #'notify_fail doesn't crash. Using an operator efun closure like #'switch, #',, or #'= does crash reliably.

0000914: compile error due to syntax + comment

Fri, 23 Aug 2024 17:24:49 +0000

Not sure if this is even worth looking into but in the first example when the SET_DATA definition is in use, the error message about the spurious character is misleading, making it difficult to troubleshoot. When the definition isn't used, the error makes sense.

#define SET_DATA(x, y) set_data(x, y)

Line has a typo, missing ) toward the end:
ob->SET_DATA("AC", CalcAC(ob->query_all_data(), itembonuses, spellbonuses, aabonuses, 0 /*skip caps*/);
2024.08.23 13:16:29 daemon/stats_d.c line 1439: Unexpected end of file (or a spurious 0x01 character) before ' softcap'.
2024.08.23 13:16:29 daemon/stats_d.c line 1439: syntax error before end of line.

If I don't use the definition:
ob->set_data("AC", CalcAC(ob->query_all_data(), itembonuses, spellbonuses, aabonuses, 0 /*skip caps*/);
'.24.08.23 13:21:29 daemon/stats_d.c line 494: syntax error before '
'.24.08.23 13:21:29 daemon/stats_d.c line 517: syntax error before ';
'.24.08.23 13:21:29 daemon/stats_d.c line 518: Bad assignment: illegal lhs (target) before '
2024.08.23 13:21:29 daemon/stats_d.c line 520: Variable level not declared before ' 65) * 5);'.
2024.08.23 13:21:29 Error in loading object: 'daemon/stats_d'.

0000910: libiconv detection broken on MacOS for system version

Sun, 21 Apr 2024 17:26:31 +0000

The configure check for detection iconv support looks for a symbol libiconv_close which is present in the GNU libiconv, but not in the iconv support by the Systemlib of Macos (and likely also not in (g)libc).
Workaround is to install a GNU libiconv via macports/fink/homebrew etc.

configure output:
checking for iconv... yes
checking if iconv takes a non-const char**... yes
checking if -liconv is needed... yes
checking for libiconv_close in -liconv... no
checking for libiconv_close in -liconv... (cached) no

excerpt from config.log:
configure:11469: checking for libiconv_close in -liconv
configure:11498: gcc -o conftest -g -O2 -fwrapv -I/usr/inet6/include conftest.c -liconv -lm >&5
Undefined symbols for architecture arm64:
"_libiconv_close", referenced from:
_main in conftest-e50b42.o
ld: symbol(s) not found for architecture arm64

The linker fails later resolving any iconv symbols, because no -liconv is passed. (Unfortunately with a quite misleading error message referencing a specific architecture.)

gcc -O2 -g access_check.o actions.o applied_decl.o array.o arraylist.o backend.o bitstrings.o call_out.o closure.o comm.o coroutine.o dumpstat.o ed.o efuns.o files.o gcollect.o hash.o heartbeat.o interpret.o lex.o lwobject.o main.o mapping.o md5.o mempools.o mregex.o mstrings.o object.o otable.o parser.o parse.o pkg-iksemel.o pkg-xml2.o pkg-idna.o pkg-mccp.o pkg-mysql.o pkg-gcrypt.o pkg-json.o pkg-python.o pkg-pgsql.o pkg-sqlite.o pkg-tls.o pkg-openssl.o pkg-gnutls.o port.o ptrtable.o random.o regexp.o sha1.o simulate.o simul_efun.o stdstrings.o stdstructs.o strfuns.o structs.o sprintf.o swap.o types.o unidata.o wiz_list.o xalloc.o -o ldmud -lm -lsqlite3 -lxml2
Undefined symbols for architecture arm64:
"_iconv", referenced from:
_add_message_text in comm.o
_iconv_opt in comm.o
_read_file_iconv in files.o
_v_write_file in files.o
_iconv_opt in files.o
__myfilbuf in lex.o
_iconv_opt in lex.o
...
"_iconv_close", referenced from:
_remove_interactive in comm.o
_remove_interactive in comm.o
_f_configure_interactive in comm.o
_set_encoding in comm.o
_set_encoding in comm.o
_set_encoding in comm.o
_f_configure_driver in efuns.o
...
"_iconv_open", referenced from:
_iconv_opt_open in comm.o
_set_encoding in comm.o
_set_encoding in comm.o
_iconv_opt_open in efuns.o
_v_read_file in files.o
_v_read_file in files.o
_get_file_encoding in files.o
_get_file_encoding in files.o
_get_file_encoding in files.o
...
ld: symbol(s) not found for architecture arm64

0000909: 3.6.7 make error

Tue, 26 Dec 2023 05:15:32 +0000

Hi. Getting this error on making 3.6.7. See attachment for full output.

./mk-patchlevel.sh
3.6.7
bison --defines=lang.h -o lang.c lang.y
lang.y:2.9-25: error: %define variable 'api.location.type' is not used
%define api.location.type {code_location_t}
^^^^^^^^^^^^^^^^^
Makefile:214: recipe for target 'lang.h' failed
make: *** [lang.h] Error 1

0000238: Colored string handling

Mon, 02 Oct 2023 16:35:30 +0000

Short: Useful coloured string efuns
From: "Alexander Weidt et al." <tubmud@cs.tu-berlin.de>
Date: Fri Feb 23 13:42:33 2001
Type: Feature
New: Acknowledged
See also: f-011016-0

Hi Lars,,

hier schick ich Dir mal die Klasse basic/coloured_string.c.

Anmerkungen:
- #define REGEXP_TERMINAL_COLOUR_TOKEN "%\\^([^%]|(%%*[^%^]))*%%*\\^"
- LIB_CNTL_SEQUENCES->get_plain_mapping() liefert ein Mapping fuer
terminal_colour(), welches alle hier im Mud definierten tokens enthaelt
und auf "" abbildet.

Viele Gruesse,

Coogan.
-----------------------------------------------------------------------
/*
* /basic/coloured_string.c by Alfe for TubMud 01-Feb-14
*
* This is a basic class for handling coloured strings.
*/

#pragma strong_types

#include
#include // Coogan, 16-Feb-01

private nosave mapping plain_mapping;

/*
* this applies `changer' on all parts of the given coloured_string
* which are not a colour token and returns the result.
*/
string apply_on_coloured_string(string coloured_string,closure changer) {
mixed h;
int i;
h = regexplode(coloured_string,REGEXP_TERMINAL_COLOUR_TOKEN);
for (i=0; i h[i] = funcall(changer,h[i]);
return implode(h,"");
}

/*
* this removes all colour tokens from the given coloured_string and
* returns the result; thus it produces a verbatim string.
*/
string to_verbatim(string coloured_string) {
if (!plain_mapping)
plain_mapping = LIB_CNTL_SEQUENCES->get_plain_mapping();
return terminal_colour(coloured_string,plain_mapping);
}

/*
* this returns the visible string length of a coloured string
*/
int strlen_visible(string coloured_string) {
if (!plain_mapping)
plain_mapping = LIB_CNTL_SEQUENCES->get_plain_mapping();
return strlen(terminal_colour(coloured_string,plain_mapping));
}

private void find_pos(string *parts,
int pos,status pos_from_back,
int real_part,int real_pos,
status as_start) {
if (pos_from_back) {
if (pos < 0) {
real_part = sizeof(parts) - 1;
real_pos = strlen(parts[<1]);
} else {
pos = strlen_visible(implode(parts,"")) - pos;
find_pos(parts,pos,0,&real_part,&real_pos,as_start);
}
} else { // from front
// skip all parts which are too short:
for (real_part = real_pos = 0;
real_part < sizeof(parts) && (as_start?
pos > strlen(parts[real_part]) :
pos >= strlen(parts[real_part]));
real_pos += strlen(parts[real_part]),
pos -= strlen(parts[real_part]),
real_part += 2)
;
if (real_part >= sizeof(parts)) { // too long?
real_part = sizeof(parts) - 1;
real_pos = strlen(parts[<1]);
} else
real_pos = pos;
}
}

/*
* this returns a substring of the given coloured string;
*/
varargs string substring(string coloured_string,
int start, int stop,
status start_from_back,status stop_from_back) {
string *parts;
int *real_pos, *vis_pos;
int i;
int real_start_pos,real_stop_pos;
int real_start_part,real_stop_part;
parts = regexplode(coloured_string,REGEXP_TERMINAL_COLOUR_TOKEN);
find_pos(parts,start,start_from_back,&real_start_part,&real_start_pos,1);
find_pos(parts, stop, stop_from_back, &real_stop_part, &real_stop_pos,0);
if (real_start_part > real_stop_part)
return "";
if (real_start_part == real_stop_part)
parts[real_start_part] =
parts[real_start_part][real_start_pos..real_stop_pos];
else {
parts[real_start_part] = parts[real_start_part][real_start_pos..];
parts[real_stop_part] = parts[real_stop_part][..real_stop_pos];
}
return implode(parts[real_start_part..real_stop_part],"");
}

varargs string coloured_sprintf(string format,varargs mixed *args) {
int i;
int strlen_diff;
for (i=0; i if (stringp(args[i+1])) {
strlen_diff = strlen(args[i+1]) - strlen_visible(args[i+1]);
if (args[i] < 0)
args[i] -= strlen_diff;
else
args[i] += strlen_diff;
}
return apply(#'sprintf,format,args);
}

Aber gleich zu [] noch was anderes: Wir haben hier die Notwendigkeit
festgestellt, farbige strings mit terminal_colour()-token an definierten
Stellen umzubrechen bzw. teilstrings zu extrahieren, und diese Extraktion
ist in LPC recht teuer.

Dies ist bisher hier so geloest in einer sefun
subcoloured_string(string coloured_string,
int start, int stop,
status start_from_back,status stop_from_back):

string s = "%^BOLD_BLUE%^Test%^NORMAL%^ %^RED%^another test%^NORMAL%^";

subcoloured_string(s, 2) == "%^BOLD_BLUE%^est%^NORMAL%^ %^RED%^another test%^NORMAL%^"
s[0..3] == "%^BOLD_BLUE%^Test%^NORMAL%^%^RED%^%^NORMAL%^"
s[5..] == "%^BOLD_BLUE%^%^NORMAL%^%^RED%^another test%^NORMAL%^"

D.h. alle Farbtokens bleiben im resultat-string drin, und extrahiert wird
letztlich der verbatim-teil dazwischen.
Die sefun zerlegt zunaechst den String in farbtokens und plain text, dann
wird das extract auf den plaintext-Stuecken vorgenommen, und danach wieder
der farb-string zusammengesetzt. Wie gesagt, sehr teuer.

Aber hierbei koennen wir wirklich wieder in Probleme laufen, wenn man das
in [] machen wollte. Ein Datentyp 'coloured_string' waere wirklich nett.
Und/oder natuerlich eine efun, die diese extrahierung von plain text
aus colour-token-verseuchten strings vornimmt. :-)
----------------------------------------------------------------------------
And Slava wrote in Oct 2001:

Recently I revealed great demand in something like hibrid of
sprintf+terminal_colour. Also I've discovered, that some time ago
there was something about this topic - f-990309-1.

In the matter of fact there is a great demand in such a functionality
in the driver. Till now, there are no official way, how to handle
coloured strings. I mean, yes you can do something with it - wrap,
and do very rudimentary formatting, using terminal_colour. But this is
not enough.

Furthermore, without additional and expensive workarounds, there are no
way how to:

1. format coloured string like in sprintf(), especially using such a
modifiers, like: '-=', '|=', etc.
2. measure coloured string length like in strlen() or sizeof()
3. Use all the great funs, that we have for their non-coloured
equivalents. All because of there is difference in actual string
size and its displayable one.

Subject: sprintf() and colour strings
From: Lars Duening, Alfe
Date: 2001-10-16
Type: Feature
State: Acknowledged.
See also: f-010223, f-011015-1, f-000905-1

New format specifier '%S' to format colour-coded strings, '%s' normal strings
as usual.

Optionally introduce an efun

csprintf(mapping cntl, string format, mixed args...)

which first applies sprintf(), and then replaces all colour strings in the
result before returning it.

Dafire also requested this formatting capability:

From: "Bastian Hoyer" <dafire@dafire.de>
Date: Tue, 16 Oct 2001 11:15:39 +0200

Hallo Lars,

was ich braeuchte waere ein leerzeichen das vorne am Wort klebt :)

also ich mache eine liste die so aussieht:

aaa: +bbb -ccc +ddd eee fff

vor jedem wert hab ich ein + oder - oder ein leerzeichen :)

wenn das jetzt umbricht sieht das evtl so aus :

aaa: +bbb -ccc +ddd
eee fff

weil das Leerzeichen vor eee beim umbrechen wegfaellt :)

Ich hoffe das war irgendwie verstaendlich :)
Ich glaub bei html ist das ein :)

Bastian

0000865: efun is_typeof() to check if a program is inherited

Mon, 02 Oct 2023 16:27:04 +0000

Ein Wunsch eines Magiers aus dem MG...

--- cut here ---
wenn ihr mal wieder am Driver baut: so etwas wie is_typeof(object o, str
baseloadname) waere cool.

Semantik:
return objectp(o) &&
member(program_name+".c", inherit_list(o))>=0;

Nur halt nicht so teuer :D

0000792: limited( expression ... ) would be nice

Mon, 02 Oct 2023 16:26:24 +0000

Similar to catch( expression ) it would be nice to have a variant of limited() in which one can simply write an expression out.

limited() is hugely helpful for securing critical code, but a limited( expression ... ) variant would help with adoption, as it would make adding a limited() around an expression as easy as adding a catch().

Example:

BEFORE:
err= catch( ob->fun() )

AFTER (proposed):
limited( err= catch( ob->fun() ) )

0000526: Implicit conversions of 64-bit values into 32-bit values

Thu, 06 Oct 2022 22:00:38 +0000

The gcc in MacOS X 10.5 has a switch for enabling some interesting warnings. -Wshorten-64-to-32 warns about implicit conversions (truncations) of 64-bit values into 32-bit values. This is interesting for people who use the driver on 64-bit platforms, I guess, because this conversion is generally not lossless.
I learned about this switch today and enabled it to satisfy my curiosity. ;-)
I got 643 warning during building the driver.
I will attach the build log to this bug, because I guess, at sometime we have to look into these warning, as that truncations may well cause some bugs and maybe people working on 64-bit platforms want to have a look.

0000325: array index range inconsistency

Thu, 06 Oct 2022 21:17:54 +0000

Indexing an array by range [x..y] always works, even for negative ranges. However, if you try to assign new values to the indexed part of the array, you get a Lower/Upper range index out of bounds Runtime-Error.

Example:

({0,1,2,3})[-3..1]
-> ({0,1})

({0,1,2,3})[-3..1] = ({4,5})
-> Lower range index out of bounds: -3, size: 4.

({0,1,2,3})[2..5] = ({6,7,8})
-> Upper range index out of bounds: 5, size: 4.

I like sloppyness (to a certain degree), it's actually sad to see some of it fade away in 3.3. I'm not keen on this half-and-half sloppyness, however. I'd prefer these ranges to work at all times, or never.

Now for something not completely unexpected:

({0,1,2,3})[4..-1] = ({9})
-> ({0,1,2,3,9,0,1,2,3})

Where did that 'out of bounds' error go here? And what's with the result? Although the behaviour is half documented, it doesn't make any sense to me.

0000856: Cipher list in tls.h lacks modern ciphers

Thu, 06 Oct 2022 21:00:21 +0000

Up to date tls libraries like libgnutls or libssl (from openssl) provide ciphers that are not listed in mudlib/sys/tls.h. If the define TLS_CIPHER_NAME(x) is called naively it may choke on a bad index.

0000299: Redesigning mappings, arrays, lvalues

Thu, 06 Oct 2022 20:50:02 +0000

Short: Redesigning arrays and mappings, and lvalues.
From: Lars
Date: 2002-08-13
Type: Feature
State: New

The current problem with arrays and mappings is that even though they are
by-reference objects, they implement it differently. This is most visible
in the construct lhs += rhs, which for arrays creates a copy of lhs, but not
for mappings. Reason is that in arrays the data is stored in the array header
structure, whereas mappings store the data in a separate memory block.

Strings again act like arrays even though they use a separate memory block for
the data, but otoh they are easy to duplicate and it would be unnatural
for them to be by-reference datatyps.

Having a by-reference type may feel unusual for programmers coming from other
languages, but is no functional problem.

Note: Python handles everything by reference. list.append() changes in-place,
list + x creates a new list.

Solution 1: Implement the by-reference semantics consequentially

This means:

'lhs = rhs1 + rhs2' always creates a new item, copies the content of rhs1
and rhs2 into it and then assigns the new item to lhs, freeing whatever
was in lhs before.

'lhs += rhs' takes the contents of rhs and adds them to the existing lhs.

LPC already has the semantic that lhs[] works directly on the given
array/mapping, but it might help if programmers could specify directly
that the lhs is to be made duplicated if referenced by more than one
owner. For example:

'unique lhs += rhs' would act like 'lhs = lhs + rhs'
'unique lhs[i] = j' would act like 'lhs = copy(lhs); lhs[i] = j'

'unique' could also be used in a rhs context and would act like copy().
The special form 'unique lhs1, lhs2, lhs3,...' would act like
'lhs1 = copy(lhs1); lhs2 = copy(lhs2); lhs3 = lhs(3);'

In order to implement this efficiently, it might be useful to have a
separate svalue type for arrays with fixed number of elements (structs,
tuples). Another idea would be to store the initial elements in the array
header structure, and let later changes to the array replace the first
svalue entry with a special svalue (T_ARRAY_EXTENSION) pointing to the
additional data.

The disadvantage would be that ({}) != ({}) (but ([]) != ([]) already
anyway).

Solution 2: Implement a by-value semantics.

Both 'lhs = rhs1 + rhs2' and 'lhs += rhs' create a new item, copy the
content of rhs1 and rhs2 into it and then assigns the new item to lhs,
freeing whatever was in lhs before. The advantage of using the '+='
operator would be that the interpreter can avoid duplicating lhs
if it doesn't have more than one reference.

To implement this efficiently, the driver would have to implement
a copy-on-write semantic.

To allow the sharing of arrays and mappings, programs would explicitely
create references to it, like 'return &foo'. A good implementation of
these references would be to use indirection like this:

type a = value;

a = (T_TYPE, value)

type b = &a;
type c = &b;

a = (T_LVALUE)\
b = (T_LVALUE)- (3 refs, (T_TYPE, value))
c = (T_LVALUE)/

The lvalue-resolution code would then detect and collapse lvalue
holders with only one ref left.

Handling references to subranges or single elements would require
some more effort - views maybe? One view would cache the referenced
element and write it back to the underlying structure when the
underlying structure as a whole is read, or when another view
to the same structure is about to be changed. This would imply a back-
pointer from the lvalue-holder to the list of views.

With this, the language would need a way to ignore the lvalue mode:

type a = value; type b = &a;

b = 0; --> removes value from a and b
&b = 0; --> removes value from b, but not from a
&b = 1; --> just assigns '1' to b, ignores the '&' as b is not an lvalue.

Another modification would be to allow only read access to the
reference: type b = const ref a;

0000476: Improve eval statistics gathering (patch)

Thu, 06 Oct 2022 20:11:50 +0000

This patch adds calls to mark_start_evaluation() and mark_end_evaluation() for external master applies, calls to logon() and erq_send callbacks. It also adds a mark_end_evaluation() in the global error handler

0000146: Filenames in master calls should always start with a leading '/'

Thu, 06 Oct 2022 19:48:14 +0000

This might break backwards compatibility.

0000907: Disallow addition of empty mappings with different width

Thu, 06 Oct 2022 19:47:03 +0000

Currently, empty mappings with different widths can be added, e.g. widthof(([:2]) + ([:3])) is 3.
Non-empty mappings cause a runtime error.
We currently think, there are no reasonable usecases to be able to add mappings with different widths and would like to disallow them in 3.7.

0000158: Add driver compilation options and constants to driver_info()

Thu, 06 Oct 2022 19:28:19 +0000

We need to
a) assemble a list of options/constants in config.h.in, machine.h.in, that are useful to have in LPC
b) add that to driver_info() and maybe even to configure_driver if it should be changed/is changeable.

--- historic description ---
Short: Runtime query of driver compilation options.
Date: 981114
Type: Feature
State: Proposed
Long:

The driver should offer a way to query compilation options (like MAX_BITSTRING)
at runtime, either via LPC-Predefines, or by an efun returning a mapping.

0000777: Remove memory fragmentation related configuration switches

Thu, 06 Oct 2022 18:40:16 +0000

It would be nice to remove the following switches (so remove their behaviour OR remove the conditional use): USE_AVL_FREELIST, MALLOC_ORDER_LARGE_FREELISTS and MALLOC_ORDER_SLAB_FREELISTS.

As Gnomi mentioned in 0000663:0001229 we should try to measure their impact on fragmentation.
A possibility for this might be the idea sketched in 0000663:0001232.

0000783: Change documentation to explain small_min_malloc and that it is only used in smalloc

Thu, 06 Oct 2022 18:34:37 +0000

MIN_SMALL_MALLOCED is used to allocate a certain amount of memory used for small blocks at boot time and reduce memory fragmentation. This is only done for the smalloc allocator, not slaballoc.

0000730: static logon() function does not work for TLS logon callback

Thu, 06 Oct 2022 18:16:39 +0000

For a standard connect logon() in the login object can be static.

If tls_init_connection() is called in connect() in the master, the call to logon() in the login object is delayed until TLS handshake finished and the logon() is called. In this case, logon() must not be static. This inconsistency is a bit annoying, especially because it is not documented.

However, because arbitrary callbacks can be defined with tls_init_connection(), we can't simply ignore any access modifiers when executing the callback.

0000696: Change some efuns to return structs

Thu, 06 Oct 2022 17:59:35 +0000

LDMud recently gained the capability to return structs from efuns.

We now need to define which efuns should be changed in 3.7.x.
Ideas: driver_info (DI_TRACE), ...?

--- historic/obsolete description ---
thought today of efuns returning structs.
Usually we return arrays, if efuns return more than one value. But struct are nice as well (nearly as fast, but typed). I could imagine it for efuns like object_info(), driver_info(), query_limits(), call_out_info() and such...

As far as I can see: returning structs is not a big problem (now that they are not optional anymore), but returning anonymous structs is not better than arrays. So, we would the type definitions for these structs independent of a specific program being loaded...

Some ideas: kind of simul_efun for structs? Or struct-preloads? Then we would have to supply the right struct types in LPC (write them on-the-fly?) or have them implicitly defined and 'inherited' by any program...

0000664: RfC: Remove compat mode

Thu, 06 Oct 2022 17:48:26 +0000

The efun transfer() might be emulated by a simul-efun. But the biggest problem is, that in compat mode all file and object names don't have a leading slash.

0000294: Range operator in mappings

Mon, 19 Sep 2022 22:47:31 +0000

Short: Range operators on 2d mappings
From: Lars
Date: 2002-05-07
Type: Feature
State: New

m = ([ "foo": 2; 3; 4, "spot": 7; 8; 9 ]);

m["spot",0..1] --> ({ 7, 8 })

It could be implemented such that m["spot",] always returns a flat copy of the values in the mapping.

0000753: Ranged mapping indexing

Mon, 19 Sep 2022 22:46:36 +0000

I'd like to propose ranged mapping indexing, allowing wide mapping values to be accessed as an array. For instance;

mapping map1 = ([ "a": 1; 2; 3, ]);

printf("%Q\n%Q\n", map1["a", 0..2], map1["a", <2..]);

Additionally, it would be a natural extension to use these as l-values, so -

map1["b", 1..2] = ({ 4, 5, });

Coping mapping values from one mapping to another would become a lot easier -

map2["c", ..] = map1["a", ..];

As for the closure versions of these operators, I'd suggest reusing the existing ranged closures (#'[..], #'[<..], #'[..<], #'[<..<]), accepting an additional argument as the mapping key -

funcall(#'[..], map1, "a", 0, 2) == map["a", 0..2]);

I think this would be a logical extension to the language, making wide mappings easier to manipulate. However, I understand how much time these things take and I'd like to express my gratitude for the work being done and to all contributors.

0000902: LDMud 3.6.5 python initialization time object reference crash

Mon, 19 Sep 2022 22:46:25 +0000

With LDMud 3.6.4 with Python support compiled in it was possible to have a `--python-script` argument that used `import ldmud; ldmud.Object("/some/path.c")` to get a reference to an LPC object, even while the early driver initialization is occurring and the master object is not available.

With LDMud 3.6.5 the same Python startup script causes a reliable segfault. In "Steps to Reproduce" I've included a built binary and core dump from a representative segfault.

This appears to be due to a the `current_ob` being `NULL` before master has been initialized. This in turn causes a call to `ldmud_object_create` to use `NULL` as an argument to `ref_object`, causing a panic.

Here is a GDB session with a backtrace:
```
mud@windmill2:~/dunenextnext/ldmud-3.6.5/test$ gdb --args ../src/ldmud -u-1 -E 0 --no-compat -e -N --cleanup-time -1 --reset-time -1 --max-array 0 --max-callouts 0 --max-bytes 0 --max-file 0 -s-1 -sv-1 --hard-malloc-limit unlimited --min-malloc 0 -ru0 -rm0 -rs0 --no-strict-euids --no-wizlist-file --check-refcounts --check-state 2 --access-file none --access-log none -f test --python-script startup.py -Mmaster -mt-python 65432 --debug-file ../log/result.t-python.log
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation tgresources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../src/ldmud...
warning: File "/home/mud/dunenextnext/ldmud-3.6.5/src/ldmud-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /home/mud/dunenextnext/ldmud-3.6.5/src/ldmud-gdb.py
line to your configuration file "/home/mud/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/mud/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) run
Starting program: /home/mud/dunenextnext/ldmud-3.6.5/src/ldmud -u-1 -E 0 --no-compat -e -N --cleanup-time -1 --reset-time -1 --max-array 0 --max-callouts 0 --max-bytes 0 --max-file 0 -s-1 -sv-1 --hard-malloc-limit unlimited --min-malloc 0 -ru0 -rm0 -rs0 --no-strict-euids --no-wizlist-file --check-refcounts --check-state 2 --access-file none --access-log none -f test --python-script startup.py -Mmaster -mt-python 65432 --debug-file ../log/result.t-python.log
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
2022.01.11 02:10:38 LDMud 3.6.5 (3.6.5-1-gd8f1ef68) (development)
2022.01.11 02:10:38 Seeding PRNG from /dev/urandom.
2022.01.11 02:10:38 TLS: (OpenSSL) x509 keyfile '/home/mud/dunenextnext/certs/privkey.pem', certfile '/home/mud/dunenextnext/certs/fullchain.pem'
2022.01.11 02:10:38 TLS: (OpenSSL) X509 certificate from '/home/mud/dunenextnext/certs/fullchain.pem': B3:99:2B:EC:AD:C2:AE:1C:E6:64:C1:34:97:69:F6:C8:65:63:6F:21
2022.01.11 02:10:38 TLS: (OpenSSL) trusted x509 certificates from '/home/mud/dunenextnext/certs/fullchain.pem'.
2022.01.11 02:10:38 TLS: Importing built-in default DH parameters.
2022.01.11 02:10:38 mySQL 8.0.27

Program received signal SIGSEGV, Segmentation fault.
ldmud_object_create (ob=0x0) at pkg-python.c:2943
2943 self->lpc_object = ref_object(ob, "ldmud_object_create");
(gdb) bt
#0 ldmud_object_create (ob=0x0) at pkg-python.c:2943
0000001 0x000055555565beca in svalue_to_python (svp=0x7fffffffc710) at pkg-python.c:9322
0000002 python_save_contextvar_value (contextvar=0x5555557b9c08 ,
name=0x5555556c9dbd "ldmud.current_object", object=...) at pkg-python.c:9832
0000003 python_save_context () at pkg-python.c:9857
0000004 0x0000555555660fc5 in python_call_hook_object (hook=1, is_external=, ob=0x7ffff6440b80)
at pkg-python.c:10410
0000005 0x0000555555619b4a in init_object_variables (ob=ob@entry=0x7ffff6440b80, templ=templ@entry=0x0) at object.c:494
0000006 0x000055555566ed22 in load_object (lname=lname@entry=0x7ffff644ad20 "a", create_super=create_super@entry=false,
depth=depth@entry=0, isMasterObj=isMasterObj@entry=false, chain=chain@entry=0x0) at simulate.c:2236
0000007 0x000055555566c443 in lookfor_object (str=, bLoad=bLoad@entry=true) at simulate.c:2538
0000008 0x0000555555651a25 in ldmud_object_init_getobject (num_arg=num_arg@entry=0, data=data@entry=0x7fffffffcaa0)
at pkg-python.c:2600
0000009 0x000055555565c0e9 in call_lpc_secure (fun=fun@entry=0x555555651a10 ,
num_arg=num_arg@entry=0, data=data@entry=0x7fffffffcaa0) at pkg-python.c:9759
0000010 0x000055555565c59a in ldmud_object_init (self=0x7ffff5de3540, args=, kwds=)
at pkg-python.c:2632
0000011 0x00007ffff6edd199 in ?? () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
0000012 0x00007ffff6f3cafb in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
0000013 0x00007ffff6d08df3 in ?? () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
#14 0x00007ffff6d10ef6 in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
#15 0x00007ffff6e5eecb in _PyEval_EvalCodeWithName () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
#16 0x00007ffff6e5f252 in PyEval_EvalCodeEx () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
#17 0x00007ffff6e5f63f in PyEval_EvalCode () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
#18 0x00007ffff6e200dc in ?? () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
#19 0x00007ffff6e21a47 in PyRun_SimpleFileExFlags () from /lib/x86_64-linux-gnu/libpython3.8.so.1.0
#20 0x000055555565faf6 in pkg_python_init (prog_name=) at pkg-python.c:9987
#21 0x0000555555571b52 in main (argc=, argv=0x7fffffffe158) at main.c:581
```