Docker Wordpress CPU jumps when selecting featured image - wordpress

I have a DO VPS with 1GB RAM and 1 CPU.
I started to see some issues when I selected a Featured Image. I lost the database connection, so I checked my stats both docker and DO CPU stats, and shortly after selecting an image of around 1meg in size, my wp container's CPU skyrocketed and either caused the memory to run out or just did not do anything?
Then had the following, when tried to run docker ps -a:
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x7f55471d3428 m=0
goroutine 0 [idle]:
goroutine 1 [running]:
runtime.systemstack_switch()
/usr/local/go/src/runtime/asm_amd64.s:245 fp=0xc820020770 sp=0xc820020768
runtime.main()
/usr/local/go/src/runtime/proc.go:126 +0x62 fp=0xc8200207c0 sp=0xc820020770
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc8200207c8 sp=0xc8200207c0
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1998 +0x1
rax 0x0
rbx 0x7f5547562700
rcx 0x7f55471d3428
rdx 0x6
rdi 0x17a
rsi 0x17a
rbp 0xea3bde
rsp 0x7ffdf52e7938
r8 0x7f5547563770
r9 0x7f5547ba8700
r10 0x8
r11 0x202
r12 0x2cfb050
r13 0xe6f464
r14 0x0
r15 0x8
rip 0x7f55471d3428
rflags 0x202
cs 0x33
fs 0x0
gs 0x0
Has anyone else seen something like this?
I have done a LoadImpact test which went for 5 min without any issues.
Any advice on how to troubleshoot this?

Related

ESP32 phy_init partition has no size

I want to flash the ESP32-D0WDQ6 chip, but the code will not run. In the monitor I can see that the app actually never loads. The partition phy_init does not seem to have any size and the chip gets stuck after that line.
Monitor output:
rst:0x1 (POWERON_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:6744
load:0x40078000,len:14236
ho 0 tail 12 room 4
load:0x40080400,len:3716
entry 0x40080680
I (28) boot: ESP-IDF v4.4-dev-1404-gc13afea63 2nd stage bootloader
I (28) boot: compile time 23:43:03
I (28) boot: chip revision: 1
I (32) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (40) boot.esp32: SPI Speed : 40MHz
I (44) boot.esp32: SPI Mode : DIO
I (49) boot.esp32: SPI Flash Size : 2MB
I (53) boot: Enabling RNG early entropy source...
I (59) boot: Partition Table:
I (62) boot: ## Label Usage Type ST Offset Length
I (70) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (77) boot: 1 phy_init RF data 01 01 0000f000 0000
My partition table:
nvs,data,nvs,0x9000,24K,
phy_init,data,phy,0xf000,4K,
factory,app,factory,0x10000,1M
Flash command:
esptool.py esp32 -p /dev/ttyACM0 -b 115200 --before=no_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 2MB 0x1000 bootloader/bootloader.bin 0x8000 partition_table/partition-table.bin 0x10000 my_project.bin
I actually found a solution to the problem:
This is the WiFi NINA W102 module, which has only 2MB of storage. The problem to it crashing was just another one: To keep the NINA running, the RESET pin has to be pulled high all time. The Arduino script pulls it low after some time by itself so keeping it pulled high when the code should be executed did the trick. There is still crashed but downgrading to a stable IDF version resolved every issue.

Android WebView Crash

I am showing ads in my application and getting following crash from most of the user's. Does anyone know about it?
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
eax 00000000 ebx b7677c74 ecx bf94b510 edx 00000000
esi aa24b9a1 edi bf94b6a8
xcs 00000073 xds 0000007b xes 0000007b xfs 00000007 xss 0000007b
eip b75dc610 ebp b464e2b0 esp bf94b5d0 flags 00210282
backtrace:
#00 pc 000e2610 /system/lib/libandroid_runtime.so (GraphicsJNI::getNativeCanvas(_JNIEnv*, _jobject*)+48)
#01 pc 00001744 /system/lib/libwebviewchromium_plat_support.so
#02 pc 001fa460 /system/lib/libwebviewchromium.so
#03 pc 001d0838 /system/lib/libwebviewchromium.so
#04 pc 001e4ae6 /system/lib/libwebviewchromium.so
#05 pc 0000b86c /data/dalvik-cache/x86/system#app#webview#webview.apk#classes.dex

channel 0/1 got hung up in asterisk

I am trying to make a outgoing from an asterisk pbx using .call file but every time .call file is moved in outgoing folder my cli shows
[Jun 16 15:38:12] NOTICE[30435]: pbx_spool.c:372 attempt_thread: Call failed to go through, reason (1) Hangup
[Jun 16 15:38:12] NOTICE[30435]: pbx_spool.c:375 attempt_thread: Queued call to DAHDI/g0/09716927126 expired without completion after 0 attempts
-- Span 1: Channel 0/1 got hangup request, cause 16
-- Hungup 'DAHDI/i1/09711590094-103a'
[Jun 16 15:38:17] NOTICE[30434]: pbx_spool.c:372 attempt_thread: Call failed to go through, reason (1) Hangup
[Jun 16 15:38:17] NOTICE[30434]: pbx_spool.c:375 attempt_thread: Queued call to DAHDI/g0/09711590094 expired without completion after 0 attempts
-- Attempting call on DAHDI/g0/09711590094 for 4759509#outgoing1:1 (Retry 1)
-- Attempting call on DAHDI/g0/09716927126 for 4759509#outgoing1:1 (Retry 1)
-- Requested transfer capability: 0x00 - SPEECH
-- Requested transfer capability: 0x00 - SPEECH
-- Span 1: Channel 0/2 got hangup request, cause 31
-- Hungup 'DAHDI/i1/09716927126-103d'
my .call file
Channel: DAHDI/g0/09711590094
MaxRetries: 1
RetryTime: 600
WaitTime: 30
Context: outgoing1
Extension: 10
Priority: 1
The call could not be connected.Anybody knows what would be the possible reason for that?
Thanks in advance
This error mean you can't call as requested via dahdi/g0
Very likly you have configure correctly your dahdi card.

Missing 0xF and 0x16 when binary data through virtual serial port pair created by socat

I have used following command to create a pair for serial port and trying to send binary data across them.
sudo socat -d -d pty,link=/dev/tty.vcp0,raw,echo=0,user=myusername,group=staff pty,link=/dev/tty.vcp1,raw,echo=0,user=myusername,group=staff
However, even I try to send follow binary file
data.bin
0x16 0x16 0x16 0x16 0x16 0x16
(basically just a file with 6 bytes, each byte has value 0x16)
by
cat /dev/tty.vcp0 > recv.bin
and
cat data.bin > /dev/tty.vcp1
And what I get is just 3 bytes of 0x16 instead of 6.
Similar thing happen on byte 0xF. If I send a binary file with 6 bytes of 0xF, I can't received any single byte.
Anyone know what is causing the missing 0x16 and 0xF?
How can I transfer binary data which contain 0x16 and 0xF?
Other test case:
Test case 1
Send:
0x16 0x16 0x16 0x0 0x0 0x0 0x0 0x16 0x16 0x16
Receive:
0x16 0x0 0x0 0x0 0x0 0x16
Test case 2
Send:
0xf 0xf 0xf 0x0 0x0 0x0 0x0 0xf 0xf 0xf
Receive:
0xf 0x0 0x0 0x0 0x0
I have added -x option in the socat command, and I can see the correct data being displayed, so it should the receive side's problem.
P.S. All of the above tests are carried out on Mac OS X 10.9.2
IEXTEN flag in termios.c_lflag is causing this problem.
When IEXTEN is on, VDISCARD=SI (0xF) and VLNEXT=SYN(0x16) will not pass to input as mentioned in the man page of termios.
Simplest way to fix this problem is pass iexten=0 to the socat command, such as:
sudo socat -d -d pty,link=/dev/tty.vcp0,raw,echo=0,iexten=0,user=myusername,group=staff pty,link=/dev/tty.vcp1,raw,echo=0,iexten=0,user=myusername,group=staff
The issue here most likely has to do with the way the device flushes it's buffers. The cat functions simply opens, writes the bytes, then closes the device with no regard to waiting for the data to completely run out.
Depending on what type of VCP device you are using you can configure the flush behavior so that when a device is closed it will not flush the data, instead it will just run out of the transceiver until it is done.
In a real application you would have control over this, and you could wait on the data to be received before closing the device.
A quick fix for this case is to turn up the baud rate higher so that the data leaves the device fast enough so that there is nothing in the buffer when the device is closed.

Qt on i.MX6 with -platform eglfs -> Segmentation fault

I have cross-compiled Qt 5.1.1 for an i.MX6 powered Nitrogen6x board running Debian 7 (wheezy).
I have configured Qt with the -egl parameter and eglfs has been listed as QPA backend in the configure output.
However if I try to run a small example application with the -platform eglfs parameter I am running into this error:
stdin: is not a tty
[ 1] HAL user version 4.6.9 build 6622 Aug 15 2013 13:22:40
[ 2] HAL kernel version 4.6.9 build 1210
QML debugging is enabled. Only use this in a safe environment.
bash: line 1: 3673 Segmentation fault DISPLAY=:0.0 /opt/Test/bin/Test -platform eglfs
Remote application finished with exit code 139.
OpenGL ES2 and EGL are installed on the board and can be found in /usr/lib and /usr/include.
Sadly I couldn't find proper documentation for eglfs, so I am hoping that someone around here has made some experiences with it.
This is the backtrace output:
run Test-platform eglfs
Starting program: /opt/Test/bin/Test Test -platform eglfs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[ 1] HAL user version 4.6.9 build 6622 Aug 15 2013 13:31:17
[ 2] HAL kernel version 4.6.9 build 1210
QML debugging is enabled. Only use this in a safe environment.
[New Thread 0x2c6b7460 (LWP 4057)]
Program received signal SIGSEGV, Segmentation fault.
0x2bab6f48 in gcoHAL_QueryChipCount () from /usr/lib/libGAL.so
(gdb) backrace full
Undefined command: "backrace". Try "help".
(gdb) backrace full[1#t
#0 0x2bab6f48 in gcoHAL_QueryChipCount () from /usr/lib/libGAL.so
No symbol table info available.
#1 0x2ba7ccbc in veglGetThreadData () from /usr/lib/libEGL.so.1
No symbol table info available.
#2 0x2ba74cd0 in eglBindAPI () from /usr/lib/libEGL.so.1
No symbol table info available.
#3 0x2be41934 in ?? () from /usr/local/Qt-Debian/plugins/platforms/libqeglfs.so
No symbol table info available.
#4 0x2be41934 in ?? () from /usr/local/Qt-Debian/plugins/platforms/libqeglfs.so
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0 0x1 1
r1 0x23e54 147028
r2 0x738 1848
r3 0x0 0
r4 0x2bb67d84 733379972
r5 0x23e18 146968
r6 0x2e70c 190220
r7 0x2b430198 725811608
r8 0x7efff9e8 2130704872
r9 0x8 8
r10 0x2b0725c4 721888708
r11 0x7efffae0 2130705120
r12 0x2bab6f1c 732655388
sp 0x7efff8f0 0x7efff8f0
lr 0x2ba7ccbc 732417212
pc 0x2bab6f48 0x2bab6f48 <gcoHAL_QueryChipCount+44>
cpsr 0x80000010 -2147483632
(gdb) x/16i $pc
=> 0x2bab6f48 <gcoHAL_QueryChipCount+44>: ldr r3, [r3, #12]
0x2bab6f4c <gcoHAL_QueryChipCount+48>: sub r2, r3, #1
0x2bab6f50 <gcoHAL_QueryChipCount+52>: cmp r2, #2
0x2bab6f54 <gcoHAL_QueryChipCount+56>: bhi 0x2bab6f70 <gcoHAL_QueryChipCount+84>
0x2bab6f58 <gcoHAL_QueryChipCount+60>: ldr r2, [r4]
0x2bab6f5c <gcoHAL_QueryChipCount+64>: mov r0, #0
0x2bab6f60 <gcoHAL_QueryChipCount+68>: str r3, [r1]
0x2bab6f64 <gcoHAL_QueryChipCount+72>: add r3, r2, #1
0x2bab6f68 <gcoHAL_QueryChipCount+76>: str r3, [r4]
0x2bab6f6c <gcoHAL_QueryChipCount+80>: pop {r4, pc}
0x2bab6f70 <gcoHAL_QueryChipCount+84>: mvn r0, #8
0x2bab6f74 <gcoHAL_QueryChipCount+88>: bl 0x2baad5fc
0x2bab6f78 <gcoHAL_QueryChipCount+92>: ldr r3, [r4]
0x2bab6f7c <gcoHAL_QueryChipCount+96>: mvn r0, #8
0x2bab6f80 <gcoHAL_QueryChipCount+100>: add r3, r3, #1
0x2bab6f84 <gcoHAL_QueryChipCount+104>: str r3, [r4]
(gdb) thread apply all backtrace
Thread 2 (Thread 0x2c6b7460 (LWP 4057)):
#0 0x2b52ef96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0x2b568634 in _IO_file_close () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0x2b568ffe in _IO_file_close_it () from /lib/arm-linux-gnueabihf/libc.so.6
#3 0x2b56113a in fclose () from /lib/arm-linux-gnueabihf/libc.so.6
#4 0x2bea8d00 in udev_new () from /lib/arm-linux-gnueabihf/libudev.so.0
#5 0x2be7d2e4 in ?? () from /usr/local/Qt-Debian/plugins/platforms/libqeglfs.so
#6 0x2be7d2e4 in ?? () from /usr/local/Qt-Debian/plugins/platforms/libqeglfs.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 0x2bcb9220 (LWP 4056)):
#0 0x2bab6f48 in gcoHAL_QueryChipCount () from /usr/lib/libGAL.so
#1 0x2ba7ccbc in veglGetThreadData () from /usr/lib/libEGL.so.1
#2 0x2ba74cd0 in eglBindAPI () from /usr/lib/libEGL.so.1
#3 0x2be41934 in ?? () from /usr/local/Qt-Debian/plugins/platforms/libqeglfs.so
#4 0x2be41934 in ?? () from /usr/local/Qt-Debian/plugins/platforms/libqeglfs.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit
How could I possibly fix that error?
I have the exact same crash on a MarSBoard running an egl fb application on a Yocto image created with recipes from https://github.com/silmerusse/meta-robomind.
I had to copy the EGL/OpenGL related stuff from http://repository.timesys.com/buildsources/g/gpu-viv-bin-mx6q/.
In my case galcore.ko is builtin.
Edit:
Check that you have /dev/galcore and that its permission are crw.rw.rw. (otherwise sudo chmod 666 /dev/galcore).
If you don't have /dev/galcore, try insmod /lib/modules/..../kernel/drivers/mxc/gpu-viv/galcore.ko.
These steps fixed the crash for me on an ubuntu image.
On the Yocto image the galcore driver is builtin, and seems to be there but I still get the crash.
Edit:
The crash in the Yocto image was caused by the wrong version of the EGL/GAL.so libs. Apparently the galcore driver built into the kernel has version 4.6.9.6622. It requires libs from gpu-viv-bin-mx6q-3.0.35-4.1.0. Using those libs and manually copying them into /usr/lib my fb application runs fine, using hardware OpenGLES 2.0 and hardware decoding of a h264 video.
I fixed this issue by switching to Yocto and therefor gaining access to most recent releases of essential components.
If you're developing for an i.MX cpu I strongly recommend to have a look at https://github.com/Freescale/fsl-community-bsp-platform
It is very important to remove "x11" from default-distrovars and "wayland" from poky.conf as these will cause you to run into errors.
Building Qt5 on such a setup works fine.
I got similar segfault when I forgot to load the galcore module. Here is the backtrace:
#0 0x766062b0 in gcoHAL_QueryChipCount (Hal=Hal#entry=0x0, Count=Count#entry=0x16494)
at gc_hal_user_query.c:1726
#1 0x766da244 in veglGetThreadData () at gc_egl.c:137
#2 0x766d3210 in eglfGetDisplay (display_id=0x16c08) at gc_egl_init.c:464
#3 eglGetDisplay (DisplayID=0x16c08) at gc_egl_init.c:565
Qt 5.3.2, kernel 3.10.17, Galcore version 4.6.9.9754

Resources