[Sts-sponsors] [Bug 1847924] Re: Introduce broken state parsing to mdadm
Robie, I've just updated the description with more information on the
user impact (and why we should have this patch), and also the regression
potential.
I wasn't completely right in my last comment, sorry - for RAID0/Linear
arrays, the output of the array state in "mdadm --detail" may change
after the patch _even for healthy arrays_. One example is the "readonly"
state: we can write this state to the sysfs "array_state" file for a
raid0/linear array, and currently the "mdadm --detail" will keep showing
state "clean" (arguably an odd behavior, but it is how the state output
works right now). With this patch, the state will show as "readonly".
I think we have two options here:
(a) We can backport the patch as is, hence risking some users running
monitoring tools or any kind of scripts parsing "mdadm -detail" output
breaking for raid0/linear arrays.
(b) We can introduce a conditional check for Bionic/Disco/Eoan in the
"mdadm --detail" output to keep "clean" as the array state unless it's
"active" or "broken" (the new state for failed arrays). Then, Focal will
get a merge from a more recent version of mdadm with the original patch
and diverge from this behavior, being aligned with upstream/other
distros.
Basically, the discussion is to "when" introduce the user-visible
change, if during the current releases or between releases (Focal being
the first to change). There's an hypothetical 3rd alternative that I
personally dislike and would avoid, that is introduce such conditional
check for all Ubuntu releases from now on and diverge forever from
upstream/other distros - I don't see a point in doing this.
Let me know your considerations Robie, and thanks for pointing out valid
concerns!
Cheers,
Guilherme
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1847924
Title:
Introduce broken state parsing to mdadm
Status in mdadm package in Ubuntu:
In Progress
Status in mdadm source package in Bionic:
In Progress
Status in mdadm source package in Disco:
In Progress
Status in mdadm source package in Eoan:
In Progress
Status in mdadm source package in Focal:
In Progress
Status in mdadm package in Debian:
New
Bug description:
[Impact]
* Currently, mounted raid0/md-linear arrays have no indication/warning
when one or more members are removed or suffer from some non-
recoverable error condition. The mdadm tool shows "clean" state
regardless if a member was removed.
* The patch proposed in this SRU addresses this issue by introducing a
new state "broken", which is analog to "clean" but indicates that
array is not in a good/correct state. The commit, available upstream
as 43ebc910 ("mdadm: Introduce new array state 'broken' for
raid0/linear") [0], was extensively discussed and received a good
amount of reviews/analysis by both the current mdadm maintainer as
well as an old maintainer.
* One important note here is that this patch requires a counter-part in the
kernel to be fully functional, which was SRUed in LP: #1847773.
It works fine/transparently without this kernel counter-part though.
* We had reports of users testing a scenario of failed raid0 arrays,
and getting 'clean' in mdadm proved to cause confusion and doesn't
help on noticing something went wrong with the arrays.
* The potential situation this patch (with its kernel counter-part)
addresses is: an user has raid0/linear array, and it's mounted. If one
member fails and gets removed (either physically, like a power or
firmware issue, or in software, like a driver-induced removal due to
detected failure), _without_ this patch (and its kernel counter-part)
there's nothing to let user know it failed, except filesystem errors
in dmesg. Also, non-direct writes to the filesystem will succeed, due
to how page-cache/writeback work; even a 'sync' command run will
succeed.
* The case described in above bullet was tested and the writes to
failed devices succeeded - after a reboot, the files written were
present in the array, but corrupted. An user wouldn't noticed that
unless if the writes were directed or some checksum was performed in
the files. With this patch (and its kernel counter-part), the writes
to such failed raid0/linear array are fast-failed and the filesystem
goes read-only quickly.
[Test case]
* To test this patch, create a raid0 or linear md array on Linux using
mdadm, like: "mdadm --create md0 --level=0 --raid-devices=2
/dev/nvme0n1 /dev/nvme1n1";
* Format the array using a FS of your choice (for example ext4) and
mount the array;
* Remove one member of the array, for example using sysfs interface
(for nvme: echo 1 > /sys/block/nvme0n1/device/device/remove, for scsi:
echo 1 > /sys/block/sdX/device/delete);
* Without this patch, the array state shown by "mdadm --detail" is
"clean", regardless a member is missing/failed.
[Regression
[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
** Changed in: lua-lpeg (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385
Title:
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
Status in lua-lpeg package in Ubuntu:
Fix Committed
Status in lua-lpeg source package in Xenial:
New
Status in lua-lpeg source package in Bionic:
New
Status in lua-lpeg source package in Disco:
New
Status in lua-lpeg source package in Eoan:
New
Status in lua-lpeg package in Debian:
New
Bug description:
[Impact]
Under certain conditions, lpeg will crash while walking the pattern
tree looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion
in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1847924] Re: Introduce broken state parsing to mdadm
** Description changed:
[Impact]
* Currently, mounted raid0/md-linear arrays have no indication/warning
when one or more members are removed or suffer from some non-recoverable
error condition. The mdadm tool shows "clean" state regardless if a
member was removed.
* The patch proposed in this SRU addresses this issue by introducing a
new state "broken", which is analog to "clean" but indicates that array
is not in a good/correct state. The commit, available upstream as
43ebc910 ("mdadm: Introduce new array state 'broken' for raid0/linear")
[0], was extensively discussed and received a good amount of
reviews/analysis by both the current mdadm maintainer as well as an old
maintainer.
* One important note here is that this patch requires a counter-part in the
kernel to be fully functional, which was SRUed in LP: #1847773.
It works fine/transparently without this kernel counter-part though.
+
+ * We had reports of users testing a scenario of failed raid0 arrays, and
+ getting 'clean' in mdadm proved to cause confusion and doesn't help on
+ noticing something went wrong with the arrays.
+
+ * The potential situation this patch (with its kernel counter-part)
+ addresses is: an user has raid0/linear array, and it's mounted. If one
+ member fails and gets removed (either physically, like a power or
+ firmware issue, or in software, like a driver-induced removal due to
+ detected failure), _without_ this patch (and its kernel counter-part)
+ there's nothing to let user know it failed, except filesystem errors in
+ dmesg. Also, non-direct writes to the filesystem will succeed, due to
+ how page-cache/writeback work; even a 'sync' command run will succeed.
+
+ * The case described in above bullet was tested and the writes to failed
+ devices succeeded - after a reboot, the files written were present in
+ the array, but corrupted. An user wouldn't noticed that unless if the
+ writes were directed or some checksum was performed in the files. With
+ this patch (and its kernel counter-part), the writes to such failed
+ raid0/linear array are fast-failed and the filesystem goes read-only
+ quickly.
[Test case]
* To test this patch, create a raid0 or linear md array on Linux using
mdadm, like: "mdadm --create md0 --level=0 --raid-devices=2 /dev/nvme0n1
/dev/nvme1n1";
* Format the array using a FS of your choice (for example ext4) and
mount the array;
* Remove one member of the array, for example using sysfs interface (for
nvme: echo 1 > /sys/block/nvme0n1/device/device/remove, for scsi: echo 1
> /sys/block/sdX/device/delete);
* Without this patch, the array state shown by "mdadm --detail" is
"clean", regardless a member is missing/failed.
[Regression potential]
- * There's not much potential regression here; we just exhibit arrays'
- state as "broken" if they have one or more missing/failed members; we
- believe the most common "issue" that could be reported from this patch
- is if an userspace tool rely on the array status as being always "clean"
- even for broken devices, then such tool may behave differently with this
- patch.
+ * There are mainly two potential regressions here; the first is user-
+ visible changes introduced by this mdadm patch. The second is if the
+ patch itself has some unnoticed bug.
+
+ * For the first type of potential regression: this patch introduces a
+ change in how the array state is displayed in "mdadm --detail "
+ output for raid0/linear arrays *only*. Currently, the tool shows just 2
+ states, "clean" or "active". In the patch being SRUed here, this changes
+ for raid0/linear arrays to read the sysfs array state instead. So for
+ example, we could read "readonly" state here for raid0/linear if the
+ user (or some tool) changes the array to such state. This only affects
+ raid0/linear, the output for other levels didn't change at all.
+
+ * Regarding potential unnoticed issues in the code, we changed mainly
+ structs and the "detail" command. Structs were incremented with the new
+ "broken" state and the detail output was changed for raid0/linear as
+ discussed in the previous bullet.
* Note that we *proactively* skipped Xenial SRU here, in order to
prevent potential regressions - Xenial mdadm tool lacks code
infrastructure used by this patch, so the decision was for
safety/stability, by only SRUing Bionic / Disco / Eoan mdadm versions.
[0]
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=43ebc910
[other info]
- As mdadm for focal hasn't been merged yet, this will need to be added
- there during or after merge.
+ As mdadm for focal (20.04) hasn't been merged yet, this will need to be
+ added there during or after merge.
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1847924
Title:
Introduce broken state parsing to mdadm
Status in mdadm package in
[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
[sts-sponsor]
Sponsored in focal.
# Nitpick:
I have appended the changelog to add the LP bug.
# Upstream project have no vcs, therefore no commit available. Upstream
just release tarballs.
# No merge/sync needed. Debian and Ubuntu package are already at same
version level.
# Since this is easy to reproduce using the given repro.lua program, I took
some time to double-check before final upload:
---
-> With current pkg found in the archive
$ ./repro.lua
Segmentation fault (core dumped)
-> With the just got sponsored pkg
$ ./repro.lua
root@focal:/tmp#
no segfault nor other error ^
# SRU note
As an fyi, for the continuity (SRU), since most versions are identical, please
use the following approach:
From:
lua-lpeg | 1.0.0-2 | bionic/universe
lua-lpeg | 1.0.0-2 | disco/universe
lua-lpeg | 1.0.0-2 | eoan
lua-lpeg | 1.0.0-2 | focal
To :
lua-lpeg | 1.0.0-2ubuntu0.18.04.1 | bionic/universe
lua-lpeg | 1.0.0-2ubuntu0.19.04.1 | disco/universe
lua-lpeg | 1.0.0-2ubuntu0.19.10.1 | eoan
lua-lpeg | 1.0.0-2ubuntu1 | focal
Thanks Victor for your contribution !
- Eric
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385
Title:
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
Status in lua-lpeg package in Ubuntu:
In Progress
Status in lua-lpeg source package in Xenial:
New
Status in lua-lpeg source package in Bionic:
New
Status in lua-lpeg source package in Disco:
New
Status in lua-lpeg source package in Eoan:
New
Status in lua-lpeg package in Debian:
New
Bug description:
[Impact]
Under certain conditions, lpeg will crash while walking the pattern
tree looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion
in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe :
[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
** Changed in: lua-lpeg (Ubuntu)
Importance: Undecided => Critical
** Changed in: lua-lpeg (Ubuntu)
Importance: Critical => Medium
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385
Title:
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
Status in lua-lpeg package in Ubuntu:
In Progress
Status in lua-lpeg source package in Xenial:
New
Status in lua-lpeg source package in Bionic:
New
Status in lua-lpeg source package in Disco:
New
Status in lua-lpeg source package in Eoan:
New
Status in lua-lpeg package in Debian:
New
Bug description:
[Impact]
Under certain conditions, lpeg will crash while walking the pattern
tree looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion
in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
** Changed in: lua-lpeg (Debian)
Status: Unknown => New
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385
Title:
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
Status in lua-lpeg package in Ubuntu:
In Progress
Status in lua-lpeg source package in Xenial:
New
Status in lua-lpeg source package in Bionic:
New
Status in lua-lpeg source package in Disco:
New
Status in lua-lpeg source package in Eoan:
New
Status in lua-lpeg package in Debian:
New
Bug description:
[Impact]
Under certain conditions, lpeg will crash while walking the pattern
tree looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion
in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
The attachment "focal.debdiff" seems to be a debdiff. The ubuntu-
sponsors team has been subscribed to the bug report so that they can
review and hopefully sponsor the debdiff. If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe
the team.
[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]
** Tags added: patch
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385
Title:
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
Status in lua-lpeg package in Ubuntu:
In Progress
Status in lua-lpeg source package in Xenial:
New
Status in lua-lpeg source package in Bionic:
New
Status in lua-lpeg source package in Disco:
New
Status in lua-lpeg source package in Eoan:
New
Status in lua-lpeg package in Debian:
Unknown
Bug description:
[Impact]
Under certain conditions, lpeg will crash while walking the pattern
tree looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion
in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
** Changed in: lua-lpeg (Ubuntu)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Changed in: lua-lpeg (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385
Title:
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
Status in lua-lpeg package in Ubuntu:
In Progress
Status in lua-lpeg source package in Xenial:
New
Status in lua-lpeg source package in Bionic:
New
Status in lua-lpeg source package in Disco:
New
Status in lua-lpeg source package in Eoan:
New
Status in lua-lpeg package in Debian:
Unknown
Bug description:
[Impact]
Under certain conditions, lpeg will crash while walking the pattern
tree looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion
in a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
[Sts-sponsors] [Bug 1580385] [NEW] /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
You have been subscribed to a public bug by Eric Desrochers (slashd):
[Impact]
Under certain conditions, lpeg will crash while walking the pattern tree
looking for TCapture nodes.
[Test Case]
The reproducer, taken from an upstream discussion (link in "Other
info"), is:
$ cat repro.lua
#!/usr/bin/env lua
lpeg = require "lpeg"
p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
p:match("xx")
The program crashes due to a hascaptures() infinite recursion:
$ ./repro.lua
Segmentation fault (core dumped)
(gdb) bt -25
#523984 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523985 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523986 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523987 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523988 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523989 0x77a3743c in hascaptures () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523990 0x77a3815c in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523991 0x77a388e3 in compile () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523992 0x77a36fab in ?? () from
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
#523993 0xfd1e in ?? ()
#523994 0x5556a5fc in ?? ()
#523995 0x555600c8 in ?? ()
#523996 0xf63f in ?? ()
#523997 0x5556030f in ?? ()
#523998 0xdc91 in lua_pcallk ()
#523999 0xb896 in ?? ()
#524000 0xc54b in ?? ()
#524001 0xfd1e in ?? ()
#524002 0x55560092 in ?? ()
#524003 0xf63f in ?? ()
#524004 0x5556030f in ?? ()
#524005 0xdc91 in lua_pcallk ()
#524006 0xb64b in ?? ()
#524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2,
argv=0x7fffe6d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe6c8)
at ../csu/libc-start.c:308
#524008 0xb70a in ?? ()
The expected behavior is to have the program finish normally
[Regression potential]
Low, this is a backport from upstream and only limits the infinite recursion in
a scenario where it shouldn't happen to begin with (TCapture node search).
[Other info]
This was fixed upstream in 1.0.1 by stopping the recursion in TCall
nodes and controlling that TRule nodes do not follow siblings (sib2)
The upstream discussion can be found here:
http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
td7674831.html
My analysis can be found here:
http://pastebin.ubuntu.com/p/n4824ftZt9/plain/
[Original description]
The Ubuntu Error Tracker has been receiving reports about a problem
regarding nmap. This problem was most recently seen with version
7.01-2ubuntu2, the problem page at
https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
contains more details.
** Affects: lua-lpeg (Ubuntu)
Importance: Undecided
Status: New
** Affects: lua-lpeg (Ubuntu Xenial)
Importance: Undecided
Status: New
** Affects: lua-lpeg (Ubuntu Bionic)
Importance: Undecided
Status: New
** Affects: lua-lpeg (Ubuntu Disco)
Importance: Undecided
Status: New
** Affects: lua-lpeg (Ubuntu Eoan)
Importance: Undecided
Status: New
** Affects: lua-lpeg (Debian)
Importance: Unknown
Status: Unknown
** Tags: sts wily xenial yakkety
--
/usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures
https://bugs.launchpad.net/bugs/1580385
You received this bug notification because you are a member of STS Sponsors,
which is subscribed to the bug report.
--
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help : https://help.launchpad.net/ListHelp
