Debugger error client error read econnreset

Как мне отладить ошибку ECONNRESET в Node.js?

Я запускаю приложение Express.js, используя Socket.io для веб-приложения чата, и случайно получаю следующую ошибку примерно 5 раз в течение 24 часов. Процесс узла заворачивается навсегда и сразу же перезапускается.

Проблема в том, что перезапуск Express выбивает моих пользователей из их комнат, и никто не хочет этого.

Веб-сервер прокси HAProxy. Нет проблем со стабильностью сокетов, только при использовании веб-сокетов и транспортов flashsockets. Я не могу воспроизвести это специально.

Это ошибка с узлом v0.10.11 :

РЕДАКТИРОВАТЬ (2013-07-22)

Добавлен как клиентский обработчик ошибок socket.io, так и обработчик необработанных исключений. Кажется, что этот ловит ошибку:

Поэтому я подозреваю, что это не проблема Socket.io, а HTTP-запрос к другому серверу, который я делаю, или соединение MySQL / Redis. Проблема в том, что стек ошибок не помогает мне определить мою проблему с кодом. Вот вывод журнала:

Как я знаю, что вызывает это? Как я могу получить больше от ошибки?

Хорошо, не очень многословно, но вот трассировка стека с Longjohn:

Здесь я использую файл политики флэш-сокета:

Может ли это быть причиной?

Возможно, вы уже догадались: это ошибка соединения.

«ECONNRESET» означает, что другая сторона диалога TCP внезапно закрыла свой конец соединения. Скорее всего, это связано с одной или несколькими ошибками протокола приложения. Вы можете просмотреть журналы сервера API, чтобы увидеть, если он жалуется на что-то.

Но так как вы также ищете способ проверить ошибку и, возможно, устранить ее, вы должны взглянуть на « Как отладить ошибку зависания сокета в NodeJS? », Которая была опубликована в stackoverflow по аналогичному вопросу.

Быстрое и грязное решение для разработки :

Используйте longjohn , вы получите длинные трассировки стека, которые будут содержать асинхронные операции.

Чистота и правильное решение : Технически, в узле, всякий раз , когда вы испускаете ‘error’ событие , и никто не прислушивается к нему, он будет бросать . Чтобы это не бросало, положите слушателя на него и разберитесь с этим сами. Таким образом, вы можете записать ошибку с дополнительной информацией.

Чтобы иметь одного слушателя для группы вызовов, вы можете использовать домены, а также ловить другие ошибки во время выполнения. Убедитесь, что каждая асинхронная операция, относящаяся к http (сервер / клиент), находится в различном контексте домена, по сравнению с другими частями кода, домен автоматически прослушивает error события и передает его своему собственному обработчику. Таким образом, вы только слушаете этот обработчик и получаете данные об ошибках. Вы также получите больше информации бесплатно.

РЕДАКТИРОВАТЬ (2013-07-22)

Как я уже писал выше:

«ECONNRESET» означает, что другая сторона диалога TCP внезапно закрыла свой конец соединения. Скорее всего, это связано с одной или несколькими ошибками протокола приложения. Вы можете просмотреть журналы сервера API, чтобы увидеть, если он жалуется на что-то.

Что также может иметь место: в случайное время другая сторона перегружается и в результате просто разрывает соединение. Если это так, зависит от того, к чему именно вы подключаетесь .

Но одна вещь наверняка: у вас действительно есть ошибка чтения на вашем соединении TCP, которое вызывает исключение. Это можно увидеть, посмотрев код ошибки, который вы опубликовали в своем редактировании, что подтверждает это.

Источник

nodejs to redis ECONNRESET error

For our Node.js to Redis connections, we are using the Redis npm module.

Once in a while, we are getting the following error,

The Redis setup is, One redis server in intranet and 2 Node js servers each with 8 PM2 instances running in DMZ. There is a Firewall between the node servers and the Redis server.

NODE version — 6.11.2 REDIS version — 3.2.9 PM2 version — 2.4.6

We did the TCP dump as well. The TCP dump shows some RST/ACK packets. TCP Dump

In the nodeJS, we are creating a single redis connection and are trying to use the same redis connection for all requests.

We would like to know on what exactly is causing the connection issues and why and what is the resolution.

2 Answers 2

in the /etc/redis/redis.conf file ,

Replace bind 127.0.0.1 with bind 0.0.0.0 Replace protected-mode yes with protected-mode no

and then Allow port 6379 using ufw allow 6379 and ufw allow 6379/tcp

iptables -A INPUT -p tcp —dport 6379 -j ACCEPT iptables -A INPUT -p udp —dport 6379 -j ACCEPT

sudo systemctl stop redis sudo systemctl start redis

I had the same problem with Google Firebase Cloud Functions. The problem was that latest version of Redis keep the connections alive forever. If the process that calls Redis ends shortly after it calls Redis as in our case with the Cloud Functions, you have to set the timeout setting to something different than the default 0.

You can do this by changing the timeout value in the Redis configuration file called redis.conf

The documentation says you can also set the timeout setting without restarting the instance which is not possible if your Redis instance is protected and thus cannot run something like CONFIG SET timeout 15 through the redis-cli as you would get the following error:

(error) ERR unknown command CONFIG

Источник

How do I debug error ECONNRESET in Node.js?

I’m running an Express.js application using Socket.io for a chat webapp and I get the following error randomly around 5 times during 24h. The node process is wrapped in forever and it restarts itself immediately.

The problem is that restarting Express kicks my users out of their rooms and nobody wants that.

The web server is proxied by HAProxy. There are no socket stability issues, just using websockets and flashsockets transports. I cannot reproduce this on purpose.

This is the error with Node v0.10.11 :

EDIT (2013-07-22)

Added both socket.io client error handler and the uncaught exception handler. Seems that this one catches the error:

So I suspect it’s not a Socket.io issue but an HTTP request to another server that I do or a MySQL/Redis connection. The problem is that the error stack doesn’t help me identify my code issue. Here is the log output:

How do I know what causes this? How do I get more out of the error?

Ok, not very verbose but here’s the stacktrace with Longjohn:

Here I serve the flash socket policy file:

Can this be the cause?

18 Answers 18

You might have guessed it already: it’s a connection error.

«ECONNRESET» means the other side of the TCP conversation abruptly closed its end of the connection. This is most probably due to one or more application protocol errors. You could look at the API server logs to see if it complains about something.

But since you are also looking for a way to check the error and potentially debug the problem, you should take a look at «How to debug a socket hang up error in NodeJS?» which was posted at stackoverflow in relation to an alike question.

Quick and dirty solution for development:

Use longjohn, you get long stack traces that will contain the async operations.

Clean and correct solution: Technically, in node, whenever you emit an ‘error’ event and no one listens to it, it will throw. To make it not throw, put a listener on it and handle it yourself. That way you can log the error with more information.

To have one listener for a group of calls you can use domains and also catch other errors on runtime. Make sure each async operation related to http(Server/Client) is in different domain context comparing to the other parts of the code, the domain will automatically listen to the error events and will propagate it to its own handler. So you only listen to that handler and get the error data. You also get more information for free.

EDIT (2013-07-22)

As I wrote above:

«ECONNRESET» means the other side of the TCP conversation abruptly closed its end of the connection. This is most probably due to one or more application protocol errors. You could look at the API server logs to see if it complains about something.

What could also be the case: at random times, the other side is overloaded and simply kills the connection as a result. If that’s the case, depends on what you’re connecting to exactly…

But one thing’s for sure: you indeed have a read error on your TCP connection which causes the exception. You can see that by looking at the error code you posted in your edit, which confirms it.

Источник

Picoprobe on Windows: GDBServerConsole: onBackendConnect: gdb-server program client error Error: read ECONNRESET about openocd HOT 6 OPEN

Update 1:
I did what the console told me.

IMPORTANT: Set «showDevDebugOutput»: «raw» in «launch.json» to see verbose GDB transactions here.

Now the therminal output looks like this:

embedded:startup.tcl:26: Error: Can’t find interface/raspberrypi-swd.cfg in procedure ‘script’ at file «embedded:startup.tcl», line 26

Hmmm. I’ve got a raspberrypi-swd.cfg at D:Projectspicoopenocdtclinterface . how may I tell GDP (or openocd?) that?

Michel-0 commented on January 16, 2023

Update 2:
I changed the configFiles in the launch.json from

Altough this feels like something wrong to do since this file is from pico-examples GIT, it seems like I’m one step further now.
Now I’m getting this error:

Trying to delete openocd , clone it again and configure with parameter —enable-bcm2835gpio , altough getting-started-with-pico doesn’t say anything about that parameter.

lurch commented on January 16, 2023

After lot’s of struggeling I almost think I’m the only person who tries to DEBUG an Pico on Windows

I can assure you that we did lots of testing of the instructions in the documentation, including the debugging steps, on Windows, Mac and Linux, before the release of the RP2040. But it’s possible that some of the external software in the instructions has changed in the meantime, and we’ve not had time to revisit the instructions and update them as necessary.

EDIT: A colleague also tells me that he tested the instructions on Windows 11 prior to the release of Pico W.

also I would have some feedback to the getting-started-with-pico guideline, where would be the correct place to share it?

That’s only for if you’re debugging a Pico using the GPIO pins on a Raspberry Pi (e.g. like in Chapter 5 of the Getting-Started guide), and this is also why you’re getting an error about bcm2835gpio. If you’re using one Pico to debug another Pico, then I suspect you need to use interface/picoprobe.cfg instead, as shown on page 64 of the same PDF.

In general, for these types of installation questions, you’re likely to get more help by asking at https://forums.raspberrypi.com/viewforum.php?f=143

Michel-0 commented on January 16, 2023

Trying to delete openocd, clone it again and configure with parameter —enable-bcm2835gpio, altough getting-started-with-pico doesn’t say anything about that parameter.

Failed. Hung up at the libusb is required error again I solved yesterday somehow while building openocd.

If you’re using one Pico to debug another Pico, then I suspect you need to use interface/picoprobe.cfg instead

Okay, makes sense somehow. Backuped my yesterday built openocd, changed the referenced CFG, now i got:

All those relative paths are misleading, what am I missing?
There is a D:Projectspicoopenocdtcltargetswj-dp.tcl , why doesn’t it find it?

All right, thanks, I will post something there once I’ve got it running maybe someday.

In general, for these types of installation questions, you’re likely to get more help by asking at https://forums.raspberrypi.com/viewforum.php?f=143

I already assumed so, but I’ve got no forums account (yet), so I thought I’ll try here first.

as shown on page 64 of the same PDF

That’s the description of terminal usage, isn’t it? I didn’t realize it must be changed for Visual Studio Code debugging usage, too.

EDIT:
If I turn back the launch.json «configFiles» to relative paths instead of absolute full paths it also cannot find the interface/picoprobe.cfg in the first place.

Michel-0 commented on January 16, 2023

Update:
Found https://forums.raspberrypi.com/viewtopic.php?t=301122.
Added «searchDir»: [ «D:\Projects\pico\openocd\tcl» ] to the launch.json .
Seems like one step forward. Now I get:

hmmm.
btw. system looks like that:

Michel-0 commented on January 16, 2023

In general, for these types of installation questions, you’re likely to get more help by asking at https://forums.raspberrypi.com/viewforum.php?f=143

• Unable to upload elf file — picoprobe — rp2040 HOT 3
• Build fails on MacOS HOT 6
• building openocd v0.11.0 in ubuntu 20.10 HOT 3
• flash Pico use openocd failed with
• MacOS build on Catalina 10.15 fails at libusb HOT 6
• Add hint on how to disable jimtcl
• Send changes upstream HOT 5
• Upstream v0.11.0 introduced breaking change HOT 2
• Flashing Pico w/ Jlink HOT 3
• Cannot flash nrf51822 using Picoprobe and windows build of OpenOCD HOT 6
• ./bootstrap fails . repo.or.cz is down? HOT 8
• bcm2835gpio not available after install HOT 4
• RPi and aduc7020 HOT 3
• GDB error when debugging PIO projects on VSCode
• Openocd one-liner for proper multicore RP2040 MCU reset? HOT 1
• bcm2835gpio interface not found even thought —enable-bcm2835gpio HOT 2
• Make this program portable HOT 1
• libusb errors seen on both RPiOS and macOS HOT 3
• Why can’t I find picoprobe?; on macOS Monterey HOT 4

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.

Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

TensorFlow

An Open Source Machine Learning Framework for Everyone

Django

The Web framework for perfectionists with deadlines.

Laravel

A PHP framework for web artisans

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

Some thing interesting about web. New door for the world.

server

A server is a program made to process requests and deliver data to clients.

Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

Visualization

Some thing interesting about visualization, use data art

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.

Microsoft

Open source projects and samples from Microsoft.

Источник

I’m running an Express.js application using Socket.io for a chat webapp
and I get the following error randomly around 5 times during 24h.
The node process is wrapped in forever and it restarts itself immediately.

The problem is that restarting Express kicks my users out of their rooms
and nobody wants that.

The web server is proxied by HAProxy. There are no socket stability issues,
just using websockets and flashsockets transports.
I cannot reproduce this on purpose.

This is the error with Node v0.10.11:

    events.js:72
            throw er; // Unhandled 'error' event
                  ^
    Error: read ECONNRESET     //alternatively it s a 'write'
        at errnoException (net.js:900:11)
        at TCP.onread (net.js:555:19)
    error: Forever detected script exited with code: 8
    error: Forever restarting script for 2 time

EDIT (2013-07-22)

Added both socket.io client error handler and the uncaught exception handler.
Seems that this one catches the error:

    process.on('uncaughtException', function (err) {
      console.error(err.stack);
      console.log("Node NOT Exiting...");
    });

So I suspect it’s not a Socket.io issue but an HTTP request to another server
that I do or a MySQL/Redis connection. The problem is that the error stack
doesn’t help me identify my code issue. Here is the log output:

    Error: read ECONNRESET
        at errnoException (net.js:900:11)
        at TCP.onread (net.js:555:19)

How do I know what causes this? How do I get more out of the error?

Ok, not very verbose but here’s the stacktrace with Longjohn:

    Exception caught: Error ECONNRESET
    { [Error: read ECONNRESET]
      code: 'ECONNRESET',
      errno: 'ECONNRESET',
      syscall: 'read',
      __cached_trace__:
       [ { receiver: [Object],
           fun: [Function: errnoException],
           pos: 22930 },
         { receiver: [Object], fun: [Function: onread], pos: 14545 },
         {},
         { receiver: [Object],
           fun: [Function: fireErrorCallbacks],
           pos: 11672 },
         { receiver: [Object], fun: [Function], pos: 12329 },
         { receiver: [Object], fun: [Function: onread], pos: 14536 } ],
      __previous__:
       { [Error]
         id: 1061835,
         location: 'fireErrorCallbacks (net.js:439)',
         __location__: 'process.nextTick',
         __previous__: null,
         __trace_count__: 1,
         __cached_trace__: [ [Object], [Object], [Object] ] } }

Here I serve the flash socket policy file:

    net = require("net")
    net.createServer( (socket) =>
      socket.write("<?xml version="1.0"?>n")
      socket.write("<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">n")
      socket.write("<cross-domain-policy>n")
      socket.write("<allow-access-from domain="*" to-ports="*"/>n")
      socket.write("</cross-domain-policy>n")
      socket.end()
    ).listen(843)

Can this be the cause?

Hi there,

I’m having a hard time getting my environment set up to debug a Pico on Windows 11.
In general I tried to follow the guideline getting-started-with-pico as close as possible.

Now I’m at a point where I:

• Installed the ARM GNU Toolchain
• Installed CMake
• Installed Build Tools for Visual Studio (Visual Studio already has been installed)
• Installed Python
• Git already has been installed
• Installed Visual Studio Code (after i gave up getting Visual Studio up running)
• Installed extensions C/C++, CMake, CMake Tools, Cortex-Debug for Visual Studio Code
• Cloned the pico-sdk repo and its submodules
• Cloned the pico-examples repo
• Set up Visual Studio Code like described in getting-started-with-pico and also added all necessary stuff to my PATH environment variable

Then i was able to successfully compile all pico-examples from within Visual Studio code!

But i want to be able to do online-debugging.
So i did the next steps like described in getting-started-with-pico:

• Installed MSys2
• Set up MSys2 and its packages like described in getting-started-with-pico
• Installed libusb-win32 picoprobe driver using Zadig like described in getting-started-with-pico
• Cloned openocd rp2040 branch
• Tried to build it, failed because libusb was missing
• Tried couple of things, but in the end it only worked after I: cloned libusb repo
• Build libusb and added it to PATH
• Tried again to build openocd, succeeded and added it to PATH
• Added GDB from MSys2 to PATH
• Set up Visual Studio Code like described in getting-started-with-pico (launch.json & settings.json)
• Modified the launch.json by replacing: «gdb-multiarch» by «arm-none-eabi-gdb«, «interface/raspberrypi-swd.cfg» with «interface/picoprobe.cfg«
• Added new keys to launch.json: «showDevDebugOutput«: «raw» and «searchDir«: [ «D:\Projects\pico\openocd\tcl» ]

Now I’m trying to debug the «blink» project of «pico-examples«.

Console output:

[variant] Loaded new set of variants
[kit] Successfully loaded 5 kits from C:Users***AppDataLocalCMakeToolscmake-tools-kits.json
[proc] Executing command: "C:Program Files (x86)Arm GNU Toolchain arm-none-eabi11.2 2022.02binarm-none-eabi-gcc.exe" -v
[main] Configuring folder: pico-examples 
[proc] Executing command: "C:Program FilesCMakebincmake.EXE" --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:Program Files (x86)Arm GNU Toolchain arm-none-eabi11.2 2022.02binarm-none-eabi-gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:Program Files (x86)Arm GNU Toolchain arm-none-eabi11.2 2022.02binarm-none-eabi-g++.exe" -Sd:/Projects/pico/pico-examples -Bd:/Projects/pico/pico-examples/build -G "NMake Makefiles"
[cmake] Not searching for unused variables given on the command line.
[cmake] PICO_SDK_PATH is D:/Projects/pico/pico-sdk
[cmake] PICO platform is rp2040.
[cmake] Build type is Debug
[cmake] Using regular optimized debug build (set PICO_DEOPTIMIZED_DEBUG=1 to de-optimize)
[cmake] PICO target board is pico.
[cmake] Using board configuration from D:/Projects/pico/pico-sdk/src/boards/include/boards/pico.h
[cmake] TinyUSB available at D:/Projects/pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
[cmake] Compiling TinyUSB with CFG_TUSB_DEBUG=1
[cmake] cyw43-driver available at D:/Projects/pico/pico-sdk/lib/cyw43-driver
[cmake] lwIP available at D:/Projects/pico/pico-sdk/lib/lwip
[cmake] -- Configuring done
[cmake] -- Generating done
[cmake] -- Build files have been written to: D:/Projects/pico/pico-examples/build
[main] Building folder: pico-examples blink
[build] Starting build
[proc] Executing command: "C:Program FilesCMakebincmake.EXE" --build d:/Projects/pico/pico-examples/build --config Debug --target blink -j 14 --
[build] Warning: NMake does not support parallel builds. Ignoring parallel build command line option.
[build] Scanning dependencies of target bs2_default
[build] [  0%] Built target bs2_default
[build] [  0%] Built target bs2_default_padded_checksummed_asm
[build] [  0%] Performing build step for 'ELF2UF2Build'
[build] 
[build] Microsoft (R) Program Maintenance Utility, Version 14.29.30146.0
[build] Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
[build] 
[build] [100%] Built target elf2uf2
[build] [  0%] No install step for 'ELF2UF2Build'
[build] [  0%] Completed 'ELF2UF2Build'
[build] [  0%] Built target ELF2UF2Build
[build] Scanning dependencies of target blink
[build] Consolidate compiler generated dependencies of target blink
[build] [100%] Built target blink
[build] Build finished with exit code 0

Debugging console output:

Cortex-Debug: VSCode debugger extension version 1.6.3 git(6285985). Usage info: https://github.com/Marus/cortex-debug#usage
Reading symbols from arm-none-eabi-objdump --syms -C -h -w D:/Projects/pico/pico-examples/build/blink/blink.elf
Reading symbols from arm-none-eabi-nm --defined-only -S -l -C -p D:/Projects/pico/pico-examples/build/blink/blink.elf
Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2
1-gdb-version
Launching gdb-server: openocd.exe -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "D:\Projects\pico\openocd\tcl" -f "c:/Users/***/.vscode/extensions/marus25.cortex-debug-1.6.3/support/openocd-helpers.tcl" -f interface/picoprobe.cfg -f target/rp2040.cfg
    Please check TERMINAL tab (gdb-server) for output from openocd.exe
Finished reading symbols from objdump: Time: 77 ms
Error: Unable to start GDB even after 5 seconds or it couldn't even start Make sure you can start gdb from the command-line and run any command like "echo hello".
    If you cannot, it is most likely because "libncurses5" or "python" is not installed. Some GDBs require these
Finished reading symbols from nm: Time: 510 ms
GDB could not start as expected. Bad installation or version mismatch. See if you can start gdb from a shell prompt and check its version (Must be >= 9)

Terminal output:

[2022-09-10T14:57:31.802Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
openocd.exe -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "D:\Projects\pico\openocd\tcl" -f "c:/Users/***/.vscode/extensions/marus25.cortex-debug-1.6.3/support/openocd-helpers.tcl" -f interface/picoprobe.cfg -f target/rp2040.cfg
Open On-Chip Debugger 0.11.0-g228ede4 (2022-09-09-01:28)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : only one transport option; autoselect 'swd'
adapter speed: 5000 kHz

Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 5000 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 50000
Info : Listening on port 50000 for gdb connections
[2022-09-10T14:57:32.452Z] SERVER CONSOLE DEBUG: GDBServerConsole: onBackendConnect: gdb-server program client error Error: read ECONNRESET
[2022-09-10T14:57:32.453Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...

I can barely find any help for this error. Some say to use Cortex-Debug V1.4.4 VS code extension instead of the newest, i tried that without avail, some other article sais to add a cortex-debug.openocdPath to the settings.json… also tried that resulting in failing OpenOCD to start.

So I’m pretty much clueless now… anyone some idea to help me out?

EDIT: Of course I did wire up 2 Picos like described in Appendix A «Using Picoprobe» in the getting-started-with-pico guide and flashed the Picoprobe Pico with the Picoprobe UF2.
The electrical work was the easy part… honestly I would never expect setting up a debugging workspace to be complicated like this — I worked with ARM microcontrollers before.

Kind regards,
Michel_0

Same here with NCS 1.7.0 on nRF52.

Here’s the support information (sensitive information is blanked with _____):

{
"platform": {
"os": "win32",
"osVersion": "Windows 10 Enterprise",
"osKernel": "10.0.19044",
"vscode": "1.70.2",
"electron": "18.3.5",
"node": "v16.13.2"
},
"system": {
"date": "2022-08-24T10:21:01.844Z",
"vscodeRoot": "c:\work\tools\Microsoft VS Code\resources\app",
"nrfConnectForDesktopInstalled": true,
"vscodeUptime": "01:02:17",
"osUptime": "01:02:57",
"cpu": {
"model": "Intel(R) Core(TM) i7-10810U CPU @ 1.10GHz",
"speed": "1608 MHz",
"count": 6
},
"memory": {
"total": "63.78 GB",
"free": "54.79 GB"
}
},
"workspace": {
"name": "_____",
"workspaceFile": null,
"folders": [
"c:\WORK\_____"
]
},
"extensions": {
"internal": {
"nordic-semiconductor.nrf-connect": {
"version": "2022.7.242",
"path": "c:\Users\_____\.vscode\extensions\nordic-semiconductor.nrf-connect-2022.7.242-win32-x64",
"isActive": true
},
"nordic-semiconductor.nrf-terminal": {
"version": "2022.7.21",
"path": "c:\Users\_____\.vscode\extensions\nordic-semiconductor.nrf-terminal-2022.7.21",
"isActive": true
},
"nordic-semiconductor.nrf-devicetree": {
"version": "2022.7.36",
"path": "c:\Users\_____\.vscode\extensions\nordic-semiconductor.nrf-devicetree-2022.7.36",
"isActive": true
},
"nordic-semiconductor.nrf-kconfig": {
"version": "2022.7.24",
"path": "c:\Users\_____\.vscode\extensions\nordic-semiconductor.nrf-kconfig-2022.7.24",
"isActive": true
}
},
"external": {
"marus25.cortex-debug": "1.6.0",
"ms-vscode.cpptools": "1.11.5",
"ms-vscode-remote.remote-wsl-recommender": "0.0.15",
"ms-vscode.js-debug": "1.70.0",
"ms-vscode.js-debug-companion": "1.0.18",
"ms-vscode.vscode-js-profile-table": "1.0.3",
"alefragnani.numbered-bookmarks": "8.3.1",
"cschlosser.doxdocgen": "1.4.0",
"jeff-hykin.better-cpp-syntax": "1.15.19",
"jgclark.vscode-todo-highlight": "2.0.4",
"mhutchie.git-graph": "1.30.0",
"ms-vscode.cmake-tools": "1.11.26",
"ms-vscode.cpptools-extension-pack": "1.2.0",
"ms-vscode.cpptools-themes": "1.0.0",
"trond-snekvik.gnu-mapfiles": "1.1.0",
"twxs.cmake": "0.0.17"
}
},
"tools": {
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\arm-none-eabi-gcc.exe": "9-2019-q4-major",
"C:\work\tools\SEGGER\JLink\JLink.exe": "7.58b",
"c:\work\tools\Nordic Semiconductor\nrf-command-line-tools\bin\nrfjprog.exe": "10.15.0",
"nrfutil": "Not found",
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\cmake.exe": "3.20.5",
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\Scripts\west.exe": "0.11.1",
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\python.exe": "3.8.2",
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\ninja.exe": "1.9.0",
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\gperf.exe": "3.1",
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\dtc.exe": "1.4.7",
"c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\gn.exe": "1937",
"c:\work\tools\ncs\v1.7.0\toolchain\mingw64\bin\git.exe": "2.26.2.windows.1"
},
"sdks": [
{
"version": "1.7.0",
"path": "c:\work\tools\ncs\v1.7.0"
}
],
"toolchains": [
{
"version": "1.7.0",
"path": {
"$mid": 1,
"fsPath": "c:\work\tools\ncs\v1.7.0\toolchain",
"_sep": 1,
"path": "/C:/work/tools/ncs/v1.7.0/toolchain",
"scheme": "file"
}
}
],
"connectedDevices": [
{
"serialNumber": "682895873"
}
],
"deviceProviders": [
"nrfjprog"
],
"config": {
"nordic-semiconductor.nrf-connect": {
"topdir": "${nrf-connect.sdk:1.7.0}",
"toolchain": {
"path": "${nrf-connect.toolchain:1.7.0}"
},
"ozonePath": "",
"applications": [
"${workspaceFolder}"
],
"applicationOptions": {},
"kconfig": {
"interface": "kconfig"
},
"welcome": {
"showOnStartup": false
},
"west": {
"env": {
"$base": "terminal"
}
},
"boardRoots": [],
"enableTelemetry": false,
"taskBindings": {},
"debugging": {
"backend": "Cortex-Debug"
},
"activeAppFollowActiveEditor": true
},
"nordic-semiconductor.nrf-terminal": {
"terminalMode": "character"
},
"marus25.cortex-debug": {
"armToolchainPath": null,
"armToolchainPrefix": "arm-none-eabi",
"gdbPath": null,
"objdumpPath": null,
"JLinkGDBServerPath": null,
"openocdPath": null,
"pyocdPath": null,
"PEGDBServerPath": null,
"stutilPath": null,
"stlinkPath": null,
"stm32cubeprogrammer": null,
"enableTelemetry": true,
"registerUseNaturalFormat": true,
"variableUseNaturalFormat": true,
"dbgServerLogfile": null,
"showRTOS": false,
"showDevDebugOutput": "none"
}
},
"environment": {
"westExe": "west",
"westEnv": {
"ELECTRON_RUN_AS_NODE": "1",
"HOME": "C:\Users\_____",
"HOMEDRIVE": "C:",
"HOMEPATH": "\Users\_____",
"Path": "c:\work\tools\ncs\v1.7.0\toolchain\mingw64\bin;c:\work\tools\ncs\v1.7.0\toolchain\mingw64\libexec\git-core;c:\work\tools\ncs\v1.7.0\toolchain\opt\bin;c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\Scripts;_____;c:\work\tools\Nordic Semiconductor\nrf-command-line-tools\bin\;C:\work\tools\ncs\v1.7.0\toolchain\opt\bin;C:\work\tools\SEGGER\JLink;C:\Program Files (x86)\ZBar\bin;C:\Users\_____\AppData\Local\Microsoft\WindowsApps;;C:\work\tools\Microsoft VS Code\bin",
"ZEPHYR_BASE": "c:\work\tools\ncs\v1.7.0\zephyr",
"GNUARMEMB_TOOLCHAIN_PATH": "c:\work\tools\ncs\v1.7.0\toolchain\opt",
"ZEPHYR_TOOLCHAIN_VARIANT": "gnuarmemb",
"PYTHONPATH": "c:\work\tools\ncs\v1.7.0\toolchain\opt\bin;c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\Lib;c:\work\tools\ncs\v1.7.0\toolchain\opt\bin\Lib\site-packages",
"Python3_ROOT": "c:\work\tools\ncs\v1.7.0\toolchain\opt\bin"
},
"inherited": {
"ELECTRON_RUN_AS_NODE": "1",
"HOME": "C:\Users\_____",
"HOMEDRIVE": "C:",
"HOMEPATH": "\Users\_____",
"Path": "C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;C_____;c:\work\tools\Nordic Semiconductor\nrf-command-line-tools\bin\;C:\work\tools\ncs\v1.7.0\toolchain\opt\bin;C:\work\tools\SEGGER\JLink;_____;C:\work\tools\Microsoft VS Code\bin",
"PATH": "_____c:\work\tools\Nordic Semiconductor\nrf-command-line-tools\bin\;C:\work\tools\ncs\v1.7.0\toolchain\opt\bin;C:\work\tools\SEGGER\JLink;C:\Program Files (x86)\ZBar\bin;C:\Users\_____\AppData\Local\Microsoft\WindowsApps;;C:\work\tools\Microsoft VS Code\bin"
},
"toolchainPath": "c:\work\tools\ncs\v1.7.0\toolchain",
"toolchainBinPath": "c:\work\tools\ncs\v1.7.0\toolchain\opt\bin",
"toolchainVersion": "1.7.0"
},
"terminal": {
"shell": null,
"defaultProfile": null
}
}

I guess the problem might be induced by an extension which was recently updated…

    events.js:72
            throw er; // Unhandled 'error' event
                  ^
    Error: read ECONNRESET     //alternatively it s a 'write'
        at errnoException (net.js:900:11)
        at TCP.onread (net.js:555:19)
    error: Forever detected script exited with code: 8
    error: Forever restarting script for 2 time

    process.on('uncaughtException', function (err) {
      console.error(err.stack);
      console.log("Node NOT Exiting...");
    });

    Error: read ECONNRESET
        at errnoException (net.js:900:11)
        at TCP.onread (net.js:555:19)

    Exception caught: Error ECONNRESET
    { [Error: read ECONNRESET]
      code: 'ECONNRESET',
      errno: 'ECONNRESET',
      syscall: 'read',
      __cached_trace__:
       [ { receiver: [Object],
           fun: [Function: errnoException],
           pos: 22930 },
         { receiver: [Object], fun: [Function: onread], pos: 14545 },
         {},
         { receiver: [Object],
           fun: [Function: fireErrorCallbacks],
           pos: 11672 },
         { receiver: [Object], fun: [Function], pos: 12329 },
         { receiver: [Object], fun: [Function: onread], pos: 14536 } ],
      __previous__:
       { [Error]
         id: 1061835,
         location: 'fireErrorCallbacks (net.js:439)',
         __location__: 'process.nextTick',
         __previous__: null,
         __trace_count__: 1,
         __cached_trace__: [ [Object], [Object], [Object] ] } }

    net = require("net")
    net.createServer( (socket) =>
      socket.write("<?xml version="1.0"?>n")
      socket.write("<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">n")
      socket.write("<cross-domain-policy>n")
      socket.write("<allow-access-from domain="*" to-ports="*"/>n")
      socket.write("</cross-domain-policy>n")
      socket.end()
    ).listen(843)

Ответы:

# serving the flash policy file
net = require("net")

net.createServer((socket) =>
  //just added
  socket.on("error", (err) =>
    console.log("Caught flash policy server socket error: ")
    console.log(err.stack)
  )

  socket.write("<?xml version="1.0"?>n")
  socket.write("<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">n")
  socket.write("<cross-domain-policy>n")
  socket.write("<allow-access-from domain="*" to-ports="*"/>n")
  socket.write("</cross-domain-policy>n")
  socket.end()
).listen(843)

require('net')
    .createServer( function(socket) 
    {
           // no nothing
    })
    .listen(21, function()
     {
           console.log('Socket ON')
    })

server.timeout = 0;

if (self.maxConnections && self._connections >= self.maxConnections) {
  clientHandle.close(); // causes ECONNRESET on the other end
  return;
}

net.createServer( function(socket) 
{
    for (i=0; i<1000000000; i++) ;
    socket.write("<?xml version="1.0"?>n");
…

net.createServer(function(socket)
{
    for(i=0; i<1000000000; i++);
    socket.on('error', function() { console.log("error"); });
    socket.write("<?xml version="1.0"?>n");
}

const options = { transports: ['websocket'], pingTimeout: 3000, pingInterval: 5000 };

Всем привет! Товарищи, подскажите что это значит? Я не понимаю ничего. Речь идет о боте в телеге.

Есть некая ошибка
RequestError: Error: read ECONNRESET
есть ее описание
ECONNRESET (Connection reset by peer): A connection was forcibly closed by a peer. This normally results from a loss of the connection on the remote socket due to a timeout or reboot. Commonly encountered via the http and net modules.
есть перевод описания
ECONNRESET (сброс соединения одноранговым узлом): соединение было принудительно закрыто одноранговым узлом. Обычно это происходит из-за потери соединения с удаленным сокетом из-за тайм-аута или перезагрузки. Обычно встречается через модули http и net.

Не пойму что с чем не смогло связаться? Бот с телегой? Бот с клиентом? Телега с ботом? Телега с клиентом?
Почему ошибка может быть и насколько это критично? Или это обычное явление из за проблем со связью?

I recently started learning to build Android Apps using React Native. During the course, I have to set up the Expo, an opensource platform for building native applications for Android, iOS and Web using JavaScript and React. The platform will handle the majority of work in building, deploying, and iterate native apps from the same JavaScript codebase. While building the app using the command expo build:android, I encountered ECONNRESET error.

E:App Development>expo build:android
read ECONNRESET
Error: read ECONNRESET
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:204:27)

Environment:

Expo Cli 3.21.5
System: Windows 10
Binaries: Node 12.18.0
IDEs: Visual Studio Code
Emulator: Android Emulator – Nexus Q (v10)

Well, In this tutorial I’ll explain how to solve the error – Read ECONNRESET

Fix Read ECONNRESET error

The ECONNRESET error means the TCP conversation has abruptly closed the connection!

Firstly verify that you’ve followed the instructions from the Expo on Building Standalone Apps.

Option 1: You may try deleting .expo folder and then build the app.

Option 2: If option 1 didn’t work, then you can try disabling the Windows Firewall. In my case, this option fixed the issue as the Firewall was blocking the connection to the expo build server.