text:
oob in SDL_InvalidateMap

This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:

poc (oob.tar.gz, application/gzip, 2019-05-05 03:04:23 +0000, 12032 bytes)
[PATCH] pcx: cast size and check calloc return value (CVE-2019-12222.patch, text/plain, 2019-05-28 14:23:35 +0000, 1594 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2019-05-05 03:04:23 +0000, pwd wrote:

Created attachment 3775
poc
SDL_InvalidateMap@SDL_pixels.c:979-13___SEGV_UNKNOW
description
An issue was discovered in libsdl2 2.0.9 with SDL2_image-2.0.4, There is a/an SEGV_UNKNOW in function SDL_InvalidateMap at SDL_pixels.c:979-13

commandline
loadtif  @@

source
 975         return;
 976     }
 977     if (map->dst) {
 978         /* Release our reference to the surface - see the note below */
> 979         if (--map->dst->refcount <= 0) {
 980             SDL_FreeSurface(map->dst);
 981         }
 982     }
 983     map->dst = NULL;
 984     map->src_palette_version = 0;

// loadtif.c
// #include <stdio.h>
// #include <SDL.h>
// #include <SDL_image.h>
//
// int main(int argc, char * argv[]){
//         IMG_Init(IMG_INIT_TIF);//IMG_INIT_JPG);IMG_INIT_PNG
//         while(__AFL_LOOP(1000)){
//               SDL_Surface * image = IMG_Load(argv[1]);
//               if (image){
//                 SDL_FreeSurface(image);
//               }
//         }
//         IMG_Quit();
// }

bug report
ASAN:DEADLYSIGNAL
=================================================================
==14609==ERROR: AddressSanitizer: SEGV on unknown address 0x1b60013f810b (pc 0x7f7210f5a77a bp 0x7ffc84c8bd80 sp 0x7ffc84c8ba80 T0)
    # 0 0x7f7210f5a779 in SDL_InvalidateMap /src/libsdl2/src/video/SDL_pixels.c:979:13
    # 1 0x7f7210f68c3a in SDL_FreeSurface_REAL /src/libsdl2/src/video/SDL_surface.c:1221:5
    # 2 0x7f72112bc0b1 in IMG_LoadPCX_RW /src/SDL2_image-2.0.4/IMG_pcx.c:252:13
    # 3 0x7f72112a99bd in IMG_LoadTyped_RW /src/SDL2_image-2.0.4/IMG.c:195:17
    # 4 0x7f72112a8f41 in IMG_Load /src/SDL2_image-2.0.4/IMG.c:136:12
    # 5 0x4ea0f0 in main /src/loadtif.c:8:37
    # 6 0x7f720fdaf82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    # 7 0x4189e8 in _start (/src/aflbuild/installed/bin/loadtif+0x4189e8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /src/libsdl2/src/video/SDL_pixels.c:979:13 in SDL_InvalidateMap
==14609==ABORTING

others
from fuzz project pwd-libsdl2-loadtif-00
crash name pwd-libsdl2-loadtif-00-00000007-20190419.tif
Auto-generated by pyspider at 2019-04-19 00:37:05

On 2019-05-28 14:23:35 +0000, Hugo Lefeuvre wrote:

Created attachment 3799
[PATCH] pcx: cast size and check calloc return value
Patch in attachment.
summary:
bpl is stored as a signed integer. If it happens to be negative, calloc
will be called with surface->pitch (since bpl < surface->pitch). Later we
call SDL_RWread(src, buf, bpl, 1). bpl is thus cast to size_t (becoming a
very large positive value), leading to obvious oob write.
We should fail early in this case. It doesn't make sense to continue
processing such files with corrupted bpl.

(size_t) cast bpl in SDL_max so that it is preferred over surface->pitch
if it is negative
check calloc return value to catch allocation failures
make sure we don't free unallocated buf in done section

On 2019-05-28 14:24:30 +0000, Hugo Lefeuvre wrote:

This is a bug in SDL_Image.
This issue was assigned CVE-2019-12222.

On 2019-05-28 17:58:41 +0000, Ryan C. Gordon wrote:

(In reply to Hugo Lefeuvre from comment # 1)

make sure we don't free unallocated buf in done section

Minor nitpick:

if (buf) {

   SDL_free(buf);

}

There's no need to check if buf != NULL here; SDL_free correctly ignores NULLs.
Other than that, this patch looks good to me.
--ryan.

On 2019-05-28 20:02:14 +0000, Hugo Lefeuvre wrote:

Minor nitpick:

if (buf) {

   SDL_free(buf);

}

There's no need to check if buf != NULL here; SDL_free correctly ignores
NULLs.
Other than that, this patch looks good to me.

Thanks for the review. Should I submit an updated version?

On 2019-06-10 23:21:21 +0000, Sam Lantinga wrote:

This is fixed, thanks!

On 2019-06-19 10:00:35 +0000, Castro B wrote:

May i know the solution?
Castro B,
https://sparpedia.ch

On 2019-06-19 13:50:08 +0000, Sam Lantinga wrote:

https://hg.libsdl.org/SDL_image/rev/e7e9786a1a34

On 2021-02-09 12:31:45 +0000, amez365 wrote:

how does the gig economy work
Considered a haven for tech companies, entrepreneurs and savvy investors, California is home to numerous Fortune 500 companies. What’s more – it’s the most popular state for companies to base their headquarters. Currently, the headquarters of 20% of public companies in the US are in California, and it’s a trend which doesn’t show any signs of slowing down.
https://www.fieldengineer.com/blogs/how-field-engineer-helps-california-businesses-cut-costs-by-60

This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:

poc (oob.tar.gz, application/gzip, 2019-05-05 03:04:23 +0000, 12032 bytes)
[PATCH] pcx: cast size and check calloc return value (CVE-2019-12222.patch, text/plain, 2019-05-28 14:23:35 +0000, 1594 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2019-05-05 03:04:23 +0000, pwd wrote:

Created attachment 3775
poc
SDL_InvalidateMap@SDL_pixels.c:979-13___SEGV_UNKNOW
description
An issue was discovered in libsdl2 2.0.9 with SDL2_image-2.0.4, There is a/an SEGV_UNKNOW in function SDL_InvalidateMap at SDL_pixels.c:979-13

commandline
loadtif  @@

source
 975         return;
 976     }
 977     if (map->dst) {
 978         /* Release our reference to the surface - see the note below */
> 979         if (--map->dst->refcount <= 0) {
 980             SDL_FreeSurface(map->dst);
 981         }
 982     }
 983     map->dst = NULL;
 984     map->src_palette_version = 0;

// loadtif.c
// #include <stdio.h>
// #include <SDL.h>
// #include <SDL_image.h>
//
// int main(int argc, char * argv[]){
//         IMG_Init(IMG_INIT_TIF);//IMG_INIT_JPG);IMG_INIT_PNG
//         while(__AFL_LOOP(1000)){
//               SDL_Surface * image = IMG_Load(argv[1]);
//               if (image){
//                 SDL_FreeSurface(image);
//               }
//         }
//         IMG_Quit();
// }

bug report
ASAN:DEADLYSIGNAL
=================================================================
==14609==ERROR: AddressSanitizer: SEGV on unknown address 0x1b60013f810b (pc 0x7f7210f5a77a bp 0x7ffc84c8bd80 sp 0x7ffc84c8ba80 T0)
    # 0 0x7f7210f5a779 in SDL_InvalidateMap /src/libsdl2/src/video/SDL_pixels.c:979:13
    # 1 0x7f7210f68c3a in SDL_FreeSurface_REAL /src/libsdl2/src/video/SDL_surface.c:1221:5
    # 2 0x7f72112bc0b1 in IMG_LoadPCX_RW /src/SDL2_image-2.0.4/IMG_pcx.c:252:13
    # 3 0x7f72112a99bd in IMG_LoadTyped_RW /src/SDL2_image-2.0.4/IMG.c:195:17
    # 4 0x7f72112a8f41 in IMG_Load /src/SDL2_image-2.0.4/IMG.c:136:12
    # 5 0x4ea0f0 in main /src/loadtif.c:8:37
    # 6 0x7f720fdaf82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    # 7 0x4189e8 in _start (/src/aflbuild/installed/bin/loadtif+0x4189e8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /src/libsdl2/src/video/SDL_pixels.c:979:13 in SDL_InvalidateMap
==14609==ABORTING

others
from fuzz project pwd-libsdl2-loadtif-00
crash name pwd-libsdl2-loadtif-00-00000007-20190419.tif
Auto-generated by pyspider at 2019-04-19 00:37:05

On 2019-05-28 14:23:35 +0000, Hugo Lefeuvre wrote:

Created attachment 3799
[PATCH] pcx: cast size and check calloc return value
Patch in attachment.
summary:
bpl is stored as a signed integer. If it happens to be negative, calloc
will be called with surface->pitch (since bpl < surface->pitch). Later we
call SDL_RWread(src, buf, bpl, 1). bpl is thus cast to size_t (becoming a
very large positive value), leading to obvious oob write.
We should fail early in this case. It doesn't make sense to continue
processing such files with corrupted bpl.

(size_t) cast bpl in SDL_max so that it is preferred over surface->pitch
if it is negative
check calloc return value to catch allocation failures
make sure we don't free unallocated buf in done section

On 2019-05-28 14:24:30 +0000, Hugo Lefeuvre wrote:

This is a bug in SDL_Image.
This issue was assigned CVE-2019-12222.

On 2019-05-28 17:58:41 +0000, Ryan C. Gordon wrote:

(In reply to Hugo Lefeuvre from comment # 1)

make sure we don't free unallocated buf in done section

Minor nitpick:

if (buf) {

   SDL_free(buf);

}

There's no need to check if buf != NULL here; SDL_free correctly ignores NULLs.
Other than that, this patch looks good to me.
--ryan.

On 2019-05-28 20:02:14 +0000, Hugo Lefeuvre wrote:

Minor nitpick:

if (buf) {

   SDL_free(buf);

}

There's no need to check if buf != NULL here; SDL_free correctly ignores
NULLs.
Other than that, this patch looks good to me.

Thanks for the review. Should I submit an updated version?

On 2019-06-10 23:21:21 +0000, Sam Lantinga wrote:

This is fixed, thanks!

On 2019-06-19 10:00:35 +0000, Castro B wrote:

May i know the solution?
Castro B,
https://sparpedia.ch

On 2019-06-19 13:50:08 +0000, Sam Lantinga wrote:

https://hg.libsdl.org/SDL_image/rev/e7e9786a1a34

On 2021-02-09 12:31:45 +0000, amez365 wrote:

how does the gig economy work
Considered a haven for tech companies, entrepreneurs and savvy investors, California is home to numerous Fortune 500 companies. What’s more – it’s the most popular state for companies to base their headquarters. Currently, the headquarters of 20% of public companies in the US are in California, and it’s a trend which doesn’t show any signs of slowing down.
https://www.fieldengineer.com/blogs/how-field-engineer-helps-california-businesses-cut-costs-by-60

We know that there are a lot of websites having their own lists of best products and reviews, and it can be a hell lot confusing to determine as to which one provides more reliable information than the other. We, at Reviewed Best, have a team of dedicated product experts who explore products on Amazon, research their reviews and ratings and then recommend them.

This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:

poc (oob.tar.gz, application/gzip, 2019-05-05 03:04:23 +0000, 12032 bytes)
[PATCH] pcx: cast size and check calloc return value (CVE-2019-12222.patch, text/plain, 2019-05-28 14:23:35 +0000, 1594 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2019-05-05 03:04:23 +0000, pwd wrote:

Created attachment 3775
poc
SDL_InvalidateMap@SDL_pixels.c:979-13___SEGV_UNKNOW
description
An issue was discovered in libsdl2 2.0.9 with SDL2_image-2.0.4, There is a/an SEGV_UNKNOW in function SDL_InvalidateMap at SDL_pixels.c:979-13

commandline
loadtif  @@

source
 975         return;
 976     }
 977     if (map->dst) {
 978         /* Release our reference to the surface - see the note below */
> 979         if (--map->dst->refcount <= 0) {
 980             SDL_FreeSurface(map->dst);
 981         }
 982     }
 983     map->dst = NULL;
 984     map->src_palette_version = 0;

// loadtif.c
// #include <stdio.h>
// #include <SDL.h>
// #include <SDL_image.h>
//
// int main(int argc, char * argv[]){
//         IMG_Init(IMG_INIT_TIF);//IMG_INIT_JPG);IMG_INIT_PNG
//         while(__AFL_LOOP(1000)){
//               SDL_Surface * image = IMG_Load(argv[1]);
//               if (image){
//                 SDL_FreeSurface(image);
//               }
//         }
//         IMG_Quit();
// }

bug report
ASAN:DEADLYSIGNAL
=================================================================
==14609==ERROR: AddressSanitizer: SEGV on unknown address 0x1b60013f810b (pc 0x7f7210f5a77a bp 0x7ffc84c8bd80 sp 0x7ffc84c8ba80 T0)
    # 0 0x7f7210f5a779 in SDL_InvalidateMap /src/libsdl2/src/video/SDL_pixels.c:979:13
    # 1 0x7f7210f68c3a in SDL_FreeSurface_REAL /src/libsdl2/src/video/SDL_surface.c:1221:5
    # 2 0x7f72112bc0b1 in IMG_LoadPCX_RW /src/SDL2_image-2.0.4/IMG_pcx.c:252:13
    # 3 0x7f72112a99bd in IMG_LoadTyped_RW /src/SDL2_image-2.0.4/IMG.c:195:17
    # 4 0x7f72112a8f41 in IMG_Load /src/SDL2_image-2.0.4/IMG.c:136:12
    # 5 0x4ea0f0 in main /src/loadtif.c:8:37
    # 6 0x7f720fdaf82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    # 7 0x4189e8 in _start (/src/aflbuild/installed/bin/loadtif+0x4189e8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /src/libsdl2/src/video/SDL_pixels.c:979:13 in SDL_InvalidateMap
==14609==ABORTING

others
from fuzz project pwd-libsdl2-loadtif-00
crash name pwd-libsdl2-loadtif-00-00000007-20190419.tif
Auto-generated by pyspider at 2019-04-19 00:37:05

On 2019-05-28 14:23:35 +0000, Hugo Lefeuvre wrote:

Created attachment 3799
[PATCH] pcx: cast size and check calloc return value
Patch in attachment.
summary:
bpl is stored as a signed integer. If it happens to be negative, calloc
will be called with surface->pitch (since bpl < surface->pitch). Later we
call SDL_RWread(src, buf, bpl, 1). bpl is thus cast to size_t (becoming a
very large positive value), leading to obvious oob write.
We should fail early in this case. It doesn't make sense to continue
processing such files with corrupted bpl.

(size_t) cast bpl in SDL_max so that it is preferred over surface->pitch
if it is negative
check calloc return value to catch allocation failures
make sure we don't free unallocated buf in done section

On 2019-05-28 14:24:30 +0000, Hugo Lefeuvre wrote:

This is a bug in SDL_Image.
This issue was assigned CVE-2019-12222.

On 2019-05-28 17:58:41 +0000, Ryan C. Gordon wrote:

(In reply to Hugo Lefeuvre from comment # 1)

make sure we don't free unallocated buf in done section

Minor nitpick:

if (buf) {

   SDL_free(buf);

}

There's no need to check if buf != NULL here; SDL_free correctly ignores NULLs.
Other than that, this patch looks good to me.
--ryan.

On 2019-05-28 20:02:14 +0000, Hugo Lefeuvre wrote:

Minor nitpick:

if (buf) {

   SDL_free(buf);

}

There's no need to check if buf != NULL here; SDL_free correctly ignores
NULLs.
Other than that, this patch looks good to me.

Thanks for the review. Should I submit an updated version?

On 2019-06-10 23:21:21 +0000, Sam Lantinga wrote:

This is fixed, thanks!

On 2019-06-19 10:00:35 +0000, Castro B wrote:

May i know the solution?
Castro B,
https://sparpedia.ch

On 2019-06-19 13:50:08 +0000, Sam Lantinga wrote:

https://hg.libsdl.org/SDL_image/rev/e7e9786a1a34

On 2021-02-09 12:31:45 +0000, amez365 wrote:

how does the gig economy work
Considered a haven for tech companies, entrepreneurs and savvy investors, California is home to numerous Fortune 500 companies. What’s more – it’s the most popular state for companies to base their headquarters. Currently, the headquarters of 20% of public companies in the US are in California, and it’s a trend which doesn’t show any signs of slowing down.
https://www.fieldengineer.com/blogs/how-field-engineer-helps-california-businesses-cut-costs-by-60

Of course, the first 10 seconds of your video are important in order to get the viewer’s attention, but it is also worth noting that if your video is not shown in suggestions, it will not be visible to users who will really be interested in it. In order for the video to get into suggestions, it is necessary that it has a lot of views, the https://soclikes.com/ service will help you with this, which will quickly and inexpensively wind up views for YouTube.

The Google Birthday Surprise Spinner, the greatest Doodle yet, has come around. comprising of a   turning wheel that, when turned, takes you to one of the nineteen different games, was Google's method of celebrating its nineteenth birthday. These 19 different games are very different   from each other but they are entertaining enough

license: Zlib


text:
Failing test 107 and 108 on fedora 29

Version: 1.24.0
Platform: Linux localhost.localdomain 4.18.17-300.fc29.x86_64 #1 SMP Mon Nov 5 17:56:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

After clone and checkout to v1.24.0 tag and perform instruction about building sources using autotools i got on make check
not ok 107 - getaddrinfo_fail
# exit code 134
# Output from process `getaddrinfo_fail`:
# Assertion failed in test/test-getaddrinfo.c on line 43: status < 0
not ok 108 - getaddrinfo_fail_sync
# exit code 134
# Output from process `getaddrinfo_fail_sync`:
# Assertion failed in test/test-getaddrinfo.c on line 117: 0 > uv_getaddrinfo(uv_default_loop(), &req, NULL, "xyzzy.xyzzy.xyzzy.", NULL, NULL)

Glibc version in system: glibc-2.28-17.fc29.x86_64

Thanks for the report. It probably means "xyzzy.xyzzy.xyzzy. resolves to something on your system/network. That's not a bug as such (a libuv bug anyway) so I'll go ahead and close this out. Let me know if I should reopen.

Confirm - on other network it pass without problems. I would think how this problem in test could be fixed. I was suspicious more in test rather then lib itself. Will dig in - thanks.

source: gharchive/issue

authors: bambuchaAdm bnoordhuis

repo: libuv/libuv

license: MIT

license_type: permissive

license_source: github-api


text:
Race condition in libuv console causes crash (assertion failure) on Windows

Version: Node.js v18.3.0 to all current versions, which I think is libuv v1.44.2 and up
Platform: Windows 10, Windows 11, Windows Server 2022

I originally reported this to Node.js.   Here's the original bug report: https://github.com/nodejs/node/issues/47715
I represent a team using Node.js within Microsoft.  When running Node on machines under heavy load, we have found that some Node processes fail, due to an assertion failing within /deps/uv/win/tty.c.  This is the assertion that is failing (edited for brevity):
static void uv__tty_console_signal_resize(void) {
...
  uv_mutex_lock(&uv__tty_console_resize_mutex);
  assert(uv__tty_console_width != -1 && uv__tty_console_height != -1);      <-- this fails
  if (width != uv__tty_console_width || height != uv__tty_console_height) {
...
  }
}

I believe the root cause is that there is a race condition in uv_console_init():
void uv_console_init(void) {
  if (uv_sem_init(&uv_tty_output_lock, 1))
    abort();
  uv__tty_console_handle = CreateFileW(L"CONOUT$",
                                       GENERIC_READ | GENERIC_WRITE,
                                       FILE_SHARE_WRITE,
                                       0,
                                       OPEN_EXISTING,
                                       0,
                                       0);
  if (uv__tty_console_handle != INVALID_HANDLE_VALUE) {
    CONSOLE_SCREEN_BUFFER_INFO sb_info;
    QueueUserWorkItem(uv__tty_console_resize_message_loop_thread,       <-- this starts a task in a thread pool
                      NULL,
                      WT_EXECUTELONGFUNCTION);
    uv_mutex_init(&uv__tty_console_resize_mutex);
    if (GetConsoleScreenBufferInfo(uv__tty_console_handle, &sb_info)) {
      uv__tty_console_width = sb_info.dwSize.X;
      uv__tty_console_height = sb_info.srWindow.Bottom - sb_info.srWindow.Top + 1;
    }
  }
}

This code starts a task in a thread pool, and then queries the console size.  If the thread pool task wakes up fast enough, then it will run the code that queries the console buffer size and attempts to resize it, before the first query of that console buffer succeeds, leading to the assertion failure.
Also, the worker thread can call uv_mutex_lock(&uv__tty_console_resize_mutex); before the mutex is even initialized, which would be another source of crashes.
We see this on build machines, where we spawn 140,000+ Node.js processes on machines with very large CPU counts (128 or more cores).  It is more common when running VMs than when running on bare metal (where we have rarely seen this).
We are running Node.js v18.13.0.  I have checked the sources, and this issue appears to be present in v18.13.0 and all later versions, up to and including main.
The fix should be to move the QueueUserWorkItem call after the if (GetConsoleScreenBuffer(...)) { ... } block.  That should guarantee that the mutex is properly initialized, and that the first call to GetConsoleScreenBuffer has occurred, before the resizing thread can win the race.
Reproducing
It is not easy to reproduce this bug.  We see this when running Windows builds (as in, building Windows itself), where we run more than 140,000 Node.js processes.  Even then, the frequency of this bug is 1 or 2 instances per build. That's the frequency when running on builds within VMs; when running in a host OS (no VM), the repro rate is lower (only a few observed cases).

SGTM. Could you make a PR to move that uv_mutex_init to the top of that function?

Also, I'm curious why those asserts are firing, at all.  Are asserts turned on or off in Node.js release builds?  The binary that we're running is the official release binary from the Node.js web site, v18.3.0, so it should be compiled in release mode, right?

Sure, I'd be happy to. I'd like to get the fix into both "main" and the Node.js LTS branches. What's the right way to do that?
How do changes usually flow from libuv to Node.js?

Wait until a libuv release containing the fix is released. Then that will be added to the nodejs main line and will be going down to every LTS in due time.

authors: santigimeno sivadeilra vtjnash


text:
Publish in a sbt repository

Hello,
thanks for the nice work. It would be even better if we could use it in our SBT projects without publishing locally. What about publishing to a public repository so that we can use it like this?
libraryDependencies += "org.lichess" %% "scalachess" % "10.5.0"

We publish to https://github.com/lichess-org/lila-maven.
I think the equivalent of what lila is doing is:
resolvers += Resolver.url("lila-maven", url("https://raw.githubusercontent.com/lichess-org/lila-maven/master"))
libraryDependencies += "org.lichess" %% "scalachess" % "10.5.0"

authors: FrequentlyMissedDeadlines niklasf

repo: lichess-org/scalachess


text:
Publish this as a PyPI package

We are trying to publish a PyPI package which depends on this package, but PyPI does not allow for git dependancies in the pyproject.toml.

I will take a look into it and see what I can do.

Thank you :)

I think you'll need to call the package something else on PyPI since someone else has a package called topmodel already...

Any progress?

The package should be up on pypi now under the name protein-topmodel, let me know if this works or wether you encounter any issues.

authors: OWissett janikkokot

repo: liedllab/TopModel


text:
scala-library 2.12.15 (was 2.12.10)

Updates org.scala-lang:scala-library from 2.12.10 to 2.12.15.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala-library" } ]

labels: library-update, semver-patch

Fixed with #212

source: gharchive/pull-request

authors: ennru scala-steward

repo: lightbend/sbt-paradox-apidoc


text:
Update sbt-header to 5.5.0

Updates de.heikoseeberger:sbt-header from 5.4.0 to 5.5.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "de.heikoseeberger", artifactId = "sbt-header" } ]

labels: sbt-plugin-update, semver-minor

changes at https://github.com/sbt/sbt-header/commits/master seem very minor

authors: SethTisue scala-steward

repo: lightbend/scala-sculpt


text:
🛑 Gesäuse is down

In 0a685d4, Gesäuse (https://gesaeuse.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Gesäuse is back up in bd2cf10.

repo: lightcyde/upptime


text:
Uncaught Error: Cannot find module 'viz/map'

When importing a visualization from http://localhost:3000/visualization-types/preview/?path=path/to/viz (http://localhost:3000/visualization-types/preview/?path=lightning-default-visualizations/map/ for example), it imports, but on the following screen I get the following in the browser console:
GET http://localhost:3000/js/dynamic/viz/?cachemiss=true&visualizations[]=map 500 (Internal Server Error)
_prelude.js: Uncaught Error: Cannot find module 'viz/map'

If I try opening any data using this new visualization, it appears to not be able to find the .jade file. Even when in the preview before importing, there is a section for javascript, styles, and data, but not Jade template. That leads me to believe that it isn't saving it.

and the server outputs:
Error: Cannot find module './map.jade' from '/Users/csimmons/Stash/lightning/tmp/js-build/6cb951e1-ba5b-4914-a3a7-ac8fd9bfe129/viz'

Hmm, is the jade file actually contained inside of this folder /Users/csimmons/Stash/lightning/tmp/js-build/6cb951e1-ba5b-4914-a3a7-ac8fd9bfe129/viz?
Are the other contents correct?

I'm starting to suspect this has something to do with the local import functionality, and that if you uploaded it to a secret gist and tried to import using this method:

that method the import would be successful, including the jade file.

Nope! There's no jade files in that folder, but all the other contents (js, scss) are correct.
Importing via gist does work. Weird.

authors: colesimmons mathisonian

repo: lightning-viz/lightning

license: mit

license_source: bigquery


text:
BakeSuperMacaroon on startup if it does not exist

Is your feature request related to a problem? Please describe.
Would like an easier way to bake a super macaroon.
Describe the solution you'd like
Add a config option to litd that will allow a super macaroon to be baked automatically on startup if it does not already exist.
Describe alternatives you've considered
Use the gRPC or CLI (https://lightning.engineering/api-docs/api/lit/proxy/bake-super-macaroon/) to do it manually after first creating the node. This is annoying because the user needs to coordinate a one time task to determine whether the macaroon exists or not and deal with yet another macaroon to control litd to then create the super macaroon.
Additional context
When using taproot assets, you often need to use both lnd and tapd RPC's and having to manage multiple connections to the same litd instance with multiple macaroons is a nuisance.
When creating docker containers for litd, normally the one time tasks of doing container setup are done in the Dockerfile, but litd does not normally start and create the node data until after the docker container is started and appropriate volumes are mounted. With this paradigm in mind, all other macaroons are automatically created on startup if they do not exist, and the super macaroon is an exception that I don't think we should have to deal with.

Related: I noticed that litcli ln now seems to bake it's own super macaroon in some way. Is this right? Does it create a new super macaroon every time the CLI is used? With litcli ln calls I seem to be able to use them without passing the tapd macaroon. I also saw some error in the log file if I pass the wrong macaroon, it says it can't bake a super macaroon. However, I don't see where it is writing a super macaroon to disk anywhere, so maybe it just discards it at the end of the call. Any idea what litcli ln is doing?

cc @guggero  for the question regarding what litcli ln does with respect to super macaroon baking

Yes, we use connectSuperMacClient to create a super macaroon on the fly just for the connection to tapd. We can do that if we have access to the lit.macaroon which has that capability.
Though with some of the latest changes, you should also be able to create a super macaroon using the admin.macaroon from lnd.

authors: ZZiigguurraatt ellemouton guggero

repo: lightninglabs/lightning-terminal


text:
Solved: panic: runtime error: invalid memory address or nil pointer dereference

Background
After lncli unlock  lnd crashes with panic: runtime error. it keeps crashing after a new tries of unlocking the wallet.
Your environment

version of lnd
Version: 0.10.2-beta.rc1 commit=v0.10.2-beta.rc1, build=production

which operating system (uname -a on *Nix)
Linux 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux

version of btcd, bitcoind, or other backend
Bitcoin Core version v0.20.0

Steps to reproduce
sudo systemctl stop lnd
cd /tmp
wget https://github.com/lightningnetwork/lnd/releases/download/v0.10.2-beta.rc1/lnd-linux-armv7-v0.10.2-beta.rc1.tar.gz
wget https://github.com/lightningnetwork/lnd/releases/download/v0.10.2-beta.rc1/manifest-v0.10.2-beta.rc1.txt
wget https://github.com/lightningnetwork/lnd/releases/download/v0.10.2-beta.rc1/manifest-v0.10.2-beta.rc1.txt.sig
tar -xzf lnd-linux-armv7-v0.10.2-beta.rc1.tar.gz
sudo install -m 0755 -o root -g root -t /usr/local/bin lnd-linux-armv7-v0.10.2-beta.rc1/*
sudo systemctl restart lnd
lncli unlock
Jun 19 14:46:25 pi4 lnd[19246]: Attempting automatic RPC configuration to bitcoind
Jun 19 14:46:25 pi4 lnd[19246]: Automatically obtained bitcoind's RPC credentials
Jun 19 14:46:25 pi4 lnd[19246]: 2020-06-19 14:46:25.206 [INF] LTND: Version: 0.10.2-beta.rc1 commit=v0.10.2-beta.rc1, build=production, logging=default
Jun 19 14:46:25 pi4 lnd[19246]: 2020-06-19 14:46:25.207 [INF] LTND: Active chain: Bitcoin (network=mainnet)
Jun 19 14:46:25 pi4 lnd[19246]: 2020-06-19 14:46:25.207 [INF] LTND: Opening the main database, this might take a few minutes...
Jun 19 14:46:25 pi4 lnd[19246]: 2020-06-19 14:46:25.996 [INF] CHDB: Checking for schema update: latest_version=13, db_version=13
Jun 19 14:46:25 pi4 lnd[19246]: 2020-06-19 14:46:25.996 [INF] LTND: Database now open (time_to_open=789.057668ms)!
Jun 19 14:46:26 pi4 lnd[19246]: 2020-06-19 14:46:26.000 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
Jun 19 14:46:26 pi4 lnd[19246]: 2020-06-19 14:46:26.000 [INF] RPCS: password gRPC proxy started at 127.0.0.1:xxxx
Jun 19 14:46:26 pi4 lnd[19246]: 2020-06-19 14:46:26.001 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock`
Jun 19 14:46:38 pi4 lnd[19246]: 2020-06-19 14:46:38.936 [INF] LNWL: Opened wallet
Jun 19 14:46:39 pi4 lnd[19246]: 2020-06-19 14:46:39.112 [INF] LTND: Primary chain is set to: bitcoin
Jun 19 14:46:39 pi4 lnd[19246]: 2020-06-19 14:46:39.127 [INF] LTND: Initializing bitcoind backed fee estimator in CONSERVATIVE mode
Jun 19 14:46:39 pi4 lnd[19246]: 2020-06-19 14:46:39.127 [INF] LNWL: Started listening for bitcoind transaction notifications via ZMQ on 127.0.0.1:28333
Jun 19 14:46:39 pi4 lnd[19246]: 2020-06-19 14:46:39.127 [INF] LNWL: Started listening for bitcoind block notifications via ZMQ on 127.0.0.1:28332
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.008 [INF] LNWL: The wallet has been unlocked without a time limit
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.018 [INF] LTND: LightningWallet opened
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.022 [INF] SRVR: Proxying all network traffic via Tor (stream_isolation=true)! NOTE: Ensure the backend node is
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.035 [INF] HSWC: Restoring in-memory circuit state from disk
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.036 [INF] HSWC: Payment circuits loaded: num_pending=0, num_open=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.072 [INF] HSWC: Trimming open circuits for chan_id=633409:1961:0, start_htlc_id=3
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.072 [INF] HSWC: Trimming open circuits for chan_id=634696:935:0, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.072 [INF] HSWC: Trimming open circuits for chan_id=634972:968:1, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.072 [INF] HSWC: Trimming open circuits for chan_id=633530:2055:0, start_htlc_id=4
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.073 [INF] HSWC: Trimming open circuits for chan_id=633567:2560:0, start_htlc_id=2
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.073 [INF] HSWC: Trimming open circuits for chan_id=633862:685:1, start_htlc_id=1
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.073 [INF] HSWC: Trimming open circuits for chan_id=633896:1904:0, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.073 [INF] HSWC: Trimming open circuits for chan_id=633888:501:0, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.073 [INF] HSWC: Trimming open circuits for chan_id=634285:720:0, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.073 [INF] HSWC: Trimming open circuits for chan_id=634268:349:1, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.073 [INF] HSWC: Trimming open circuits for chan_id=633896:1387:1, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.074 [INF] HSWC: Trimming open circuits for chan_id=634346:1474:1, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.074 [INF] HSWC: Trimming open circuits for chan_id=634346:1475:1, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.074 [INF] HSWC: Trimming open circuits for chan_id=634346:1442:0, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.074 [INF] HSWC: Trimming open circuits for chan_id=634343:1847:1, start_htlc_id=9
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.074 [INF] HSWC: Trimming open circuits for chan_id=634596:321:1, start_htlc_id=0
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.135 [INF] LTND: Channel backup proxy channel notifier starting
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.135 [INF] ATPL: Instantiating autopilot with active=false, max_channels=5, allocation=0.600000, min_chan_size=
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.136 [INF] RPCS: RPC server listening on 127.0.0.1:10009
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.136 [INF] RPCS: gRPC proxy started at 127.0.0.1:xxxx
Jun 19 14:46:42 pi4 lnd[19246]: 2020-06-19 14:46:42.139 [INF] LTND: Waiting for chain backend to finish sync, start_height=635412
Jun 19 14:46:43 pi4 lnd[19246]: 2020-06-19 14:46:43.252 [INF] LNWL: Started rescan from block 0000000000000000000775e41f7411d6c3ad0cf84d52497ebe7651d371bf3c1d (he
Jun 19 14:46:43 pi4 lnd[19246]: 2020-06-19 14:46:43.259 [INF] LNWL: Catching up block hashes to height 635412, this might take a while
Jun 19 14:46:43 pi4 lnd[19246]: 2020-06-19 14:46:43.260 [INF] LNWL: Done catching up block hashes
Jun 19 14:46:43 pi4 lnd[19246]: 2020-06-19 14:46:43.260 [INF] LNWL: Finished rescan for 29 addresses (synced to block 0000000000000000000775e41f7411d6c3ad0cf84d52
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.160 [INF] LTND: Chain backend is fully synced (end_height=635412)!
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.204 [INF] PRNF: PeerNotifier starting
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.208 [INF] HSWC: Starting HTLC Switch
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.208 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.209 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.273 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.294 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.337 [INF] CNCT: Creating ChannelArbitrators for 16 active channels
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.337 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.337 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.338 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.338 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.338 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.339 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.339 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.339 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.340 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.340 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.351 [INF] NTFN: New spend subscription: spend_id=3, outpoint=c6cd135bae57fe399ed378f5313f9cde91dfdacd86357504e
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.351 [INF] NTFN: Dispatching historical spend rescan for outpoint=c6cd135bae57fe399ed378f5313f9cde91dfdacd86357
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.351 [INF] NTFN: New spend subscription: spend_id=8, outpoint=738e94335b408d6ce40f45cc6664661492026db2fe21dd7c9
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.351 [INF] NTFN: Dispatching historical spend rescan for outpoint=738e94335b408d6ce40f45cc6664661492026db2fe21d
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: New spend subscription: spend_id=9, outpoint=8103dc490fb8ec55c94fff15609310c60e3f4075bf7f7c4ce
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: Dispatching historical spend rescan for outpoint=8103dc490fb8ec55c94fff15609310c60e3f4075bf7f7
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: New spend subscription: spend_id=1, outpoint=bab0cd99786d5056e66d2169b1cee6f85370ba3be18ebc51a
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: Dispatching historical spend rescan for outpoint=bab0cd99786d5056e66d2169b1cee6f85370ba3be18eb
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: New spend subscription: spend_id=4, outpoint=44ec135f4b3c077e5a6e2e193b46fc984381f8855d7be8584
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: Dispatching historical spend rescan for outpoint=44ec135f4b3c077e5a6e2e193b46fc984381f8855d7be
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: New spend subscription: spend_id=5, outpoint=64a1270c53d877bffb0ba474b6da9872f1774a0a9a5f6a8fc
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: Dispatching historical spend rescan for outpoint=64a1270c53d877bffb0ba474b6da9872f1774a0a9a5f6
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.352 [INF] NTFN: New spend subscription: spend_id=6, outpoint=e15efb7a93963eec40c459d6a07ac455547da33061df4a3cd
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.353 [INF] NTFN: Dispatching historical spend rescan for outpoint=e15efb7a93963eec40c459d6a07ac455547da33061df4
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.353 [INF] NTFN: New spend subscription: spend_id=7, outpoint=d609fbd898bb885f7d7e675fddbbcc9b57f6355f529bfd928
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.353 [INF] NTFN: Dispatching historical spend rescan for outpoint=d609fbd898bb885f7d7e675fddbbcc9b57f6355f529bf
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.353 [INF] NTFN: New spend subscription: spend_id=10, outpoint=8f35621a6adcd5cdeda66e3df97a8195e0bcd6b71d8f50ff
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.353 [INF] NTFN: Dispatching historical spend rescan for outpoint=8f35621a6adcd5cdeda66e3df97a8195e0bcd6b71d8f5
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.353 [INF] NTFN: New spend subscription: spend_id=11, outpoint=615445af8f035481cdcdecc423af12ea2288d806822ee104
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.353 [INF] NTFN: Dispatching historical spend rescan for outpoint=615445af8f035481cdcdecc423af12ea2288d806822ee
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: New spend subscription: spend_id=12, outpoint=ea90a105eba955a66bc1d6bad3c0e849561c4b4f5b36ccca
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: Dispatching historical spend rescan for outpoint=ea90a105eba955a66bc1d6bad3c0e849561c4b4f5b36c
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: New spend subscription: spend_id=2, outpoint=a5524302a1a9ccb0f776c8a9b3519ddf85ecc27bc44fbc364
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: Dispatching historical spend rescan for outpoint=a5524302a1a9ccb0f776c8a9b3519ddf85ecc27bc44fb
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: New spend subscription: spend_id=13, outpoint=c8229dbc46755af3485a4c21ef0ebdfdc1ea76f51dcfb6d8
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: Dispatching historical spend rescan for outpoint=c8229dbc46755af3485a4c21ef0ebdfdc1ea76f51dcfb
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: New spend subscription: spend_id=14, outpoint=efaff1b64895ad7e9d5d9cad4a0cd481dc9013c9778ef198
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: Dispatching historical spend rescan for outpoint=efaff1b64895ad7e9d5d9cad4a0cd481dc9013c9778ef
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.354 [INF] NTFN: New spend subscription: spend_id=15, outpoint=60edf9ed541a49461fdb07377f7eedfb5c8c586061b61b0d
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.355 [INF] NTFN: Dispatching historical spend rescan for outpoint=60edf9ed541a49461fdb07377f7eedfb5c8c586061b61
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.552 [INF] CNCT: ChannelArbitrator(c6cd135bae57fe399ed378f5313f9cde91dfdacd86357504eae792de4e46ab44:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.555 [INF] CNCT: ChannelArbitrator(9980d9eb56b90c8ec79303501fba56b81a04078afd97dea372906d09426fad25:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.557 [INF] CNCT: ChannelArbitrator(44ec135f4b3c077e5a6e2e193b46fc984381f8855d7be85849391b3564d8bc6b:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.560 [INF] CNCT: ChannelArbitrator(d609fbd898bb885f7d7e675fddbbcc9b57f6355f529bfd928f1f22c96d974c85:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.563 [INF] CNCT: ChannelArbitrator(e15efb7a93963eec40c459d6a07ac455547da33061df4a3cd71f9bbc038b848b:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.565 [INF] CNCT: ChannelArbitrator(615445af8f035481cdcdecc423af12ea2288d806822ee1045c28cb5a5f2e78d1:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.568 [INF] CNCT: ChannelArbitrator(60edf9ed541a49461fdb07377f7eedfb5c8c586061b61b0d339c78ea8b61a315:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.570 [INF] CNCT: ChannelArbitrator(efaff1b64895ad7e9d5d9cad4a0cd481dc9013c9778ef1983eaebd08afbb98a7:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.573 [INF] CNCT: ChannelArbitrator(ea90a105eba955a66bc1d6bad3c0e849561c4b4f5b36cccaa77c96ce084c6e6c:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.575 [INF] CNCT: ChannelArbitrator(8f35621a6adcd5cdeda66e3df97a8195e0bcd6b71d8f50ffdecc9bd5964ec3ce:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.578 [INF] CNCT: ChannelArbitrator(8103dc490fb8ec55c94fff15609310c60e3f4075bf7f7c4ced0160c33bc0315c:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.580 [INF] CNCT: ChannelArbitrator(738e94335b408d6ce40f45cc6664661492026db2fe21dd7c9f9144f22d3c5a4e:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.583 [INF] CNCT: ChannelArbitrator(bab0cd99786d5056e66d2169b1cee6f85370ba3be18ebc51a039be65d7d22211:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.585 [INF] CNCT: ChannelArbitrator(c8229dbc46755af3485a4c21ef0ebdfdc1ea76f51dcfb6d8bf530ae74c078225:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.588 [INF] CNCT: ChannelArbitrator(a5524302a1a9ccb0f776c8a9b3519ddf85ecc27bc44fbc364ac277311945d380:1): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.590 [INF] CNCT: ChannelArbitrator(64a1270c53d877bffb0ba474b6da9872f1774a0a9a5f6a8fc96485607daed844:0): startin
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.601 [INF] DISC: Authenticated Gossiper is starting
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.601 [INF] BRAR: Starting contract observer, watching for breaches.
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.601 [INF] NTFN: New block epoch subscription
Jun 19 14:46:44 pi4 lnd[19246]: 2020-06-19 14:46:44.606 [INF] CRTR: FilteredChainView starting
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.458 [INF] CRTR: Filtering chain using 37823 channels active
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.463 [INF] CRTR: Prune tip for Channel Graph: height=635412, hash=0000000000000000000775e41f7411d6c3ad0cf84d524
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.681 [INF] CHFT: Adding 16 channels to event store
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.682 [INF] CHBU: Starting chanbackup.SubSwapper

Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.705 [WRN] CHBU: Replacing disk backup for ChannelPoint(64a1270c53d877bffb0ba474b6da9872f1774a0a9a5f6a8fc964856
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.705 [WRN] CHBU: Replacing disk backup for ChannelPoint(bab0cd99786d5056e66d2169b1cee6f85370ba3be18ebc51a039be6
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.705 [WRN] CHBU: Replacing disk backup for ChannelPoint(a5524302a1a9ccb0f776c8a9b3519ddf85ecc27bc44fbc364ac2773
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.705 [WRN] CHBU: Replacing disk backup for ChannelPoint(9980d9eb56b90c8ec79303501fba56b81a04078afd97dea372906d0
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.705 [WRN] CHBU: Replacing disk backup for ChannelPoint(e15efb7a93963eec40c459d6a07ac455547da33061df4a3cd71f9bb
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.705 [WRN] CHBU: Replacing disk backup for ChannelPoint(738e94335b408d6ce40f45cc6664661492026db2fe21dd7c9f9144f
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(44ec135f4b3c077e5a6e2e193b46fc984381f8855d7be85849391b3
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(8103dc490fb8ec55c94fff15609310c60e3f4075bf7f7c4ced0160c
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(c8229dbc46755af3485a4c21ef0ebdfdc1ea76f51dcfb6d8bf530ae
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(615445af8f035481cdcdecc423af12ea2288d806822ee1045c28cb5
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(ea90a105eba955a66bc1d6bad3c0e849561c4b4f5b36cccaa77c96c
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(c6cd135bae57fe399ed378f5313f9cde91dfdacd86357504eae792d
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(8f35621a6adcd5cdeda66e3df97a8195e0bcd6b71d8f50ffdecc9bd
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(60edf9ed541a49461fdb07377f7eedfb5c8c586061b61b0d339c78e
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(d609fbd898bb885f7d7e675fddbbcc9b57f6355f529bfd928f1f22c
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.706 [WRN] CHBU: Replacing disk backup for ChannelPoint(efaff1b64895ad7e9d5d9cad4a0cd481dc9013c9778ef1983eaebd0
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.709 [INF] CHBU: Updating backup file at /home/bitcoin/.lnd/data/chain/bitcoin/mainnet/channel.backup
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.711 [INF] CHBU: Swapping old multi backup file from /home/bitcoin/.lnd/data/chain/bitcoin/mainnet/temp-dont-us
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.712 [INF] BTCN: Server listening on 127.0.0.1:xxxx
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.756 [INF] SRVR: Initializing peer network bootstrappers!
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.756 [INF] SRVR: Creating DNS peer bootstrapper with seeds: [[nodes.lightning.directory soa.nodes.lightning.dir
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.756 [INF] DISC: Attempting to bootstrap with: Authenticated Channel Graph
Jun 19 14:46:45 pi4 lnd[19246]: 2020-06-19 14:46:45.771 [INF] DISC: Obtained 3 addrs to bootstrap network with
Jun 19 14:46:46 pi4 lnd[19246]: 2020-06-19 14:46:46.957 [INF] SRVR: Established connection to: 02a04446caa81636d60d63b066f2814cbd3a6b5c258e3172cbdded7a16e2cfff4c@
Jun 19 14:46:46 pi4 lnd[19246]: 2020-06-19 14:46:46.957 [INF] SRVR: Finalizing connection to 02a04446caa81636d60d63b066f2814cbd3a6b5c258e3172cbdded7a16e2cfff4c@3.
Jun 19 14:46:46 pi4 lnd[19246]: panic: runtime error: invalid memory address or nil pointer dereference
Jun 19 14:46:46 pi4 lnd[19246]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x12218]
Jun 19 14:46:46 pi4 lnd[19246]: goroutine 688 [running]:
Jun 19 14:46:46 pi4 lnd[19246]: github.com/lightningnetwork/lnd.(*peer).writeMessage.func1(0x2a2a1c8, 0x39943d0)
Jun 19 14:46:46 pi4 lnd[19246]:         github.com/lightningnetwork/lnd/peer.go:1618 +0x134
Jun 19 14:46:46 pi4 lnd[19246]: github.com/lightningnetwork/lnd.(*peer).writeMessage(0x2aba400, 0xf62320, 0x2cda970, 0x8, 0xaa4858)
Jun 19 14:46:46 pi4 lnd[19246]:         github.com/lightningnetwork/lnd/peer.go:1651 +0x108
Jun 19 14:46:46 pi4 lnd[19246]: github.com/lightningnetwork/lnd.(*peer).sendInitMsg(0x2aba400, 0xc4f9a7, 0x10)
Jun 19 14:46:46 pi4 lnd[19246]:         github.com/lightningnetwork/lnd/peer.go:2698 +0x78
Jun 19 14:46:46 pi4 lnd[19246]: github.com/lightningnetwork/lnd.(*peer).Start(0x2aba400, 0xdce8c0, 0x28b2500)
Jun 19 14:46:46 pi4 lnd[19246]:         github.com/lightningnetwork/lnd/peer.go:337 +0xb0
Jun 19 14:46:46 pi4 lnd[19246]: github.com/lightningnetwork/lnd.(*server).peerInitializer(0x28b2500, 0x2aba400)
Jun 19 14:46:46 pi4 lnd[19246]:         github.com/lightningnetwork/lnd/server.go:2888 +0xcc
Jun 19 14:46:46 pi4 lnd[19246]: created by github.com/lightningnetwork/lnd.(*server).peerConnected
Jun 19 14:46:46 pi4 lnd[19246]:         github.com/lightningnetwork/lnd/server.go:2815 +0x3d8
Jun 19 14:46:47 pi4 systemd[1]: lnd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jun 19 14:46:47 pi4 systemd[1]: lnd.service: Failed with result 'exit-code'.

Expected behaviour
lnd daemon keeps running without crash
Actual behaviour
lnd daemon stops with panic: runtime error: invalid memory address or nil pointer dereference

Thank you for reporting!
It looks like we forgot to include a bugfix commit. I pushed it to the branch v0.10.2-beta-rc1-branch, can you test with 33b14fd711abae3988554cb0147bb1c7e5ab46b8 please?

Hi,
I am not so tecnically skilled. I don't know how to build it from source code (shame shame i know :-( ) Can you build the binary again please for the armv7? Regards, Michael

We are probably going to create an official RC2 next week.
Here's a build for armv7, signed with my key (8E4256593F177720, see also https://keybase.io/guggero/):
lnd-linux-armv7-20200619-01.tar.gz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

bf72508e8be7b8c31fa50cba1884c591dc6f1d8d1fa69a3f99f1a16e84e2a396  lnd-linux-armv7-20200619-01.tar.gz
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEbgHuyWVpA7BUK48QA9tjIiZ8NzsFAl7sxzQACgkQA9tjIiZ8
Nzsrbgf/aazEZa8942i7EDkCJQu4lAqLDlfCaARzEDFP7APY28MOv3wagLcIyaEh
UqCc5bbhlcqaEy62255AF/jXsQrBr/xENA3hux+8xSprGI/n7OeMZMfWuge4T8Lu
5pr9nx7NwSRHfBgcjgEB3bHYJBJehiaYSTD+n/9XEwuPXx9FXyJHr2bdgXCTOA6v
FSaJjPsEcS/1fN+MKfmLbCNFyX+QWM0v/FfzpXWj5Mwgl5xH1UzM38wEkJT9Gv+S
LD4bzuXLLX7Xa40y2pibkZh4kDZQkU3zmjlkxhiIsHc6XJo2+FpmDI6nH5ivdkkP
R+iKMtDIC/GrsT2izJVkoEl92TLIfw==
=Rje0
-----END PGP SIGNATURE-----

cd /tmp
wget https://github.com/lightningnetwork/lnd/files/4805010/lnd-linux-armv7-20200619-01.tar.gz
tar -xzf lnd-linux-armv7-20200619-01.tar.gz
sudo install -m 0755 -o root -g root -t /usr/local/bin lnd-linux-armv7-v0.10.2-beta.rc1/*
sudo systemctl restart lnd
lncli unlock

gives the same crash
Jun 19 16:17:09 pi4 lnd[19947]: panic: runtime error: invalid memory address or nil pointer dereference
Jun 19 16:17:09 pi4 lnd[19947]: [signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x12218]
Jun 19 16:17:09 pi4 lnd[19947]: goroutine 743 [running]:
Jun 19 16:17:09 pi4 lnd[19947]: github.com/lightningnetwork/lnd.(*peer).writeMessage.func1(0x399e580, 0x537cb00)
Jun 19 16:17:09 pi4 lnd[19947]:         github.com/lightningnetwork/lnd/peer.go:1618 +0x134
Jun 19 16:17:09 pi4 lnd[19947]: github.com/lightningnetwork/lnd.(*peer).writeMessage(0x61fe600, 0xf62320, 0x50a9ae8, 0x8, 0xaa4858)
Jun 19 16:17:09 pi4 lnd[19947]:         github.com/lightningnetwork/lnd/peer.go:1651 +0x108
Jun 19 16:17:09 pi4 lnd[19947]: github.com/lightningnetwork/lnd.(*peer).sendInitMsg(0x61fe600, 0xc4f9a7, 0x10)
Jun 19 16:17:09 pi4 lnd[19947]:         github.com/lightningnetwork/lnd/peer.go:2698 +0x78
Jun 19 16:17:09 pi4 lnd[19947]: github.com/lightningnetwork/lnd.(*peer).Start(0x61fe600, 0xdce8c0, 0x39a2500)
Jun 19 16:17:09 pi4 lnd[19947]:         github.com/lightningnetwork/lnd/peer.go:337 +0xb0
Jun 19 16:17:09 pi4 lnd[19947]: github.com/lightningnetwork/lnd.(*server).peerInitializer(0x39a2500, 0x61fe600)
Jun 19 16:17:09 pi4 lnd[19947]:         github.com/lightningnetwork/lnd/server.go:2888 +0xcc
Jun 19 16:17:09 pi4 lnd[19947]: created by github.com/lightningnetwork/lnd.(*server).peerConnected
Jun 19 16:17:09 pi4 lnd[19947]:         github.com/lightningnetwork/lnd/server.go:2815 +0x3d8
Jun 19 16:17:09 pi4 systemd[1]: lnd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jun 19 16:17:09 pi4 systemd[1]: lnd.service: Failed with result 'exit-code'.
Jun 19 16:17:39 pi4 systemd[1]: lnd.service: Service RestartSec=30s expired, scheduling restart.
Jun 19 16:17:39 pi4 systemd[1]: lnd.service: Scheduled restart job, restart counter is at 1.
Jun 19 16:17:39 pi4 systemd[1]: Stopped LND Lightning Network Daemon.
Jun 19 16:17:39 pi4 systemd[1]: Started LND Lightning Network Daemon.
Jun 19 16:17:40 pi4 lnd[19983]: Attempting automatic RPC configuration to bitcoind
Jun 19 16:17:40 pi4 lnd[19983]: Automatically obtained bitcoind's RPC credentials
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.070 [INF] LTND: Version: 0.10.2-beta.rc1 commit=v0.10.2-beta.rc1, build=production, logging=default
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.070 [INF] LTND: Active chain: Bitcoin (network=mainnet)
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.070 [INF] LTND: Opening the main database, this might take a few minutes...
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.819 [INF] CHDB: Checking for schema update: latest_version=13, db_version=13
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.819 [INF] LTND: Database now open (time_to_open=748.411166ms)!
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.822 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.823 [INF] RPCS: password gRPC proxy started at 127.0.0.1:49152
Jun 19 16:17:40 pi4 lnd[19983]: 2020-06-19 16:17:40.823 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock`
Jun 19 16:17:42 pi4 lnd[19983]: 2020-06-19 16:17:42.321 [INF] LTND: Received terminated
Jun 19 16:17:42 pi4 lnd[19983]: 2020-06-19 16:17:42.321 [INF] LTND: Shutting down...
Jun 19 16:17:42 pi4 lnd[19983]: 2020-06-19 16:17:42.321 [INF] LTND: Gracefully shutting down.
Jun 19 16:17:42 pi4 systemd[1]: Stopping LND Lightning Network Daemon...
Jun 19 16:17:42 pi4 lnd[19983]: 2020-06-19 16:17:42.324 [ERR] LTND: Unable to set up wallet password listeners: shutting down
Jun 19 16:17:42 pi4 lnd[19983]: 2020-06-19 16:17:42.341 [INF] LTND: Shutdown complete
Jun 19 16:17:42 pi4 lnd[19983]: Unable to set up wallet password listeners: shutting down
Jun 19 16:17:42 pi4 systemd[1]: lnd.service: Main process exited, code=exited, status=1/FAILURE
Jun 19 16:17:42 pi4 systemd[1]: lnd.service: Failed with result 'exit-code'.
Jun 19 16:17:42 pi4 systemd[1]: Stopped LND Lightning Network Daemon.

:-( very sorry to report this :-(. Maybe i am doing something wrong...?

It looks like you installed the old version again: sudo install -m 0755 -o root -g root -t /usr/local/bin lnd-linux-armv7-v0.10.2-beta.rc1/*
This should be sudo install -m 0755 -o root -g root -t /usr/local/bin lnd-linux-armv7-20200619-01/*

sudo install -m 0755 -o root -g root -t /usr/local/bin lnd-linux-armv7-20200619-01/*
jep saw it too. It works fine.
Thank you can i tip you some sats :-) for your hard work? Thank you very much

Cool, appreciate your testing effort!
No tip necessary, but thank you very much :)

authors: MykelSIlver guggero

repo: lightningnetwork/lnd