Crash On Replace SphinxQL #321
Comments
|
could you upload your index data (realtime_media_123) to write-only FTP for customer data: to reproduce this crash locally here? Just create folder there. |
|
Getting permission denied.
local: rt_123.zip remote: rt_123.zip
200 PORT command successful
550 rt_123.zip: Operation not permitted
ftp>
On Thursday, March 26, 2020, 11:43:32 a.m. EDT, Stas <[email protected]> wrote:
could you upload your index data (realtime_media_123) to write-only FTP for customer data:
ftp: dev.manticoresearch.com
user: manticorebugs
pass: shithappens
to reproduce this crash locally here?
Just create folder there.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
you need to create folder there like github-321 |
|
I created rt_123. Same issue
…Sent from my iPhone
On Mar 26, 2020, at 1:58 PM, Stas ***@***.***> wrote:
you need to create folder there like github-321
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
here it said https://github.com/manticoresoftware/manticoresearch/wiki/Write-only-FTP Could you follow the notice? |
|
Done.
On Thursday, March 26, 2020, 02:14:20 p.m. EDT, Stas <[email protected]> wrote:
here it said https://github.com/manticoresoftware/manticoresearch/wiki/Write-only-FTP
For issues opened in github please use for the folder name github-issue-XXX, where XXX is the issue number. You can upload your files with data related to the issue into the folder (subfolders are prohibited, so if your data has complex structure, pack it into single tarball).
Could you follow the notice?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Done... |
|
you uploaded RT index with invalid RAM part - it is a realtimemedia_123.ram.new file. Seems you copy index during RAM flush and that RAM part has incomplete data and daemon crashes on loading such index. Could you stop your daemon then create archive with index files? then upload it into FTP. |
tomatolog
added
more data needed
waiting
|
On its way again.Dave
On Friday, March 27, 2020, 03:32:51 a.m. EDT, Stas <[email protected]> wrote:
you uploaded RT index with invalid RAM part - it is a realtimemedia_123.ram.new file. Seems you copy index during RAM flush and that RAM part has incomplete data and daemon crashes on loading such index.
Could you stop your daemon then create archive with index files? then upload it into FTP.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I tested query that causes the initial crash with latest index you provided and see not issue there. I got correct reply with these ids Seems index got changed since crash and I can not reproduce the issue you initially reported. Could you upload your index right after the crash in case daemon crashed next time? |
|
or provide another way to reproduce issue here locally. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Feel free to re-open the issue in case it becomes actual. |
------- FATAL: CRASH DUMP -------
[Thu Mar 26 09:30:36.104 2020] [67062]
--- crashed SphinxAPI request dump ---
AAABGQAAAf4AAAAAAAAAAQAAAAAAAAAQAAAABgAAAAAAAAAEAAAAF3VwbG9hZCBERVNDLHVwbG9hZCBERVNDAAAA
AAAAAAAAAAAScmVhbHRpbWVfbWVkaWFfMTIzAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAKAAAAEG1vZGVy
YXRpb25zdGF0dXMAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAV2aG9zdAAAAAAAAAABAAAAAAAAAHsAAAAA
AAAAA2dpZAAAAAAAAAABAAAAAAAGc7kAAAAAAAAAC2NoYW5uZWxsZWZ0AAAAAQAAAAAAAAChAAAAAAAA
ASoAAAAAAAAABnN0YXR1cwAAAAAAAAABAAAAAAAAAAMAAAAAAAAAB2NvbnRleHQAAAAAAAAAAQAA
AAAAAAABAAAAAAAAAAZoaWRkZW4AAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAhmaWxldHlwZQAAAAAAAAAB
AAAAAAAAAAEAAAAAAAAAD2xhdGl0dWRlcmFkaWFucwAAAAI/SakgP02ukAAAAAAAAAAQbG9uZ2l0dWRl
cmFkaWFucwAAAAK/pC7Gv6IsDgAAAAAAAAAAAAAAAAAPQkAAAAALQGdyb3VwIGRlc2MAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASo=
--- request dump end ---
--- local index:
Manticore 3.4.0 0686d9f@200326 release
Handling signal 11
-------------- backtrace begins here ---------------
Program compiled with 7
Configured with flags: Configured by CMake with these definitions: -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDISTR_BUILD=bionic -DUSE_SSL=ON -DDL_UNIXODBC=1 -DUNIXODBC_LIB=libodbc.so.2 -DDL_EXPAT=1 -DEXPAT_LIB=libexpat.so.1 -DUSE_LIBICONV=1 -DDL_MYSQL=1 -DMYSQL_LIB=libmysqlclient.so.20 -DDL_PGSQL=1 -DPGSQL_LIB=libpq.so.5 -DLOCALDATADIR=/var/data -DFULL_SHARE_DIR=/usr/share/manticore -DUSE_ICU=1 -DUSE_BISON=ON -DUSE_FLEX=ON -DUSE_SYSLOG=1 -DWITH_EXPAT=1 -DWITH_ICONV=ON -DWITH_MYSQL=1 -DWITH_ODBC=ON -DWITH_PGSQL=1 -DWITH_RE2=1 -DWITH_STEMMER=1 -DWITH_ZLIB=ON -DGALERA_SOVERSION=31 -DSYSCONFDIR=/etc/manticoresearch
Host OS is Linux runner-72989761-project-3858465-concurrent-0 4.19.78-coreos #1 SMP Mon Oct 14 22:56:39 -00 2019 x86_64 x86_64 x86_64 GNU/Linux
Stack bottom = 0x7f42d4d77e97, thread stack size = 0x100000
Trying manual backtrace:
Frame pointer is null, manual backtrace failed (did you build with -fomit-frame-pointer?)
Trying system backtrace:
begin of system symbols:
/usr/bin/searchd(_Z12sphBacktraceib 0xcb)[0x55fb1c90be6b]
/usr/bin/searchd(_ZN16SphCrashLogger_c11HandleCrashEi 0x1d1)[0x55fb1c76dd11]
/lib/x86_64-linux-gnu/libpthread.so.0( 0x12890)[0x7f43b5eba890]
/usr/bin/searchd(_Z11sphUnzipIntRPKh 0xa)[0x55fb1c86574a]
/usr/bin/searchd(_ZNK12DocstoreRT_c6GetDocEjPK11VecTraits_TIiElb 0x220)[0x55fb1caf63f0]
/usr/bin/searchd(_ZNK9RtIndex_c6GetDocER13DocstoreDoc_tlPK11VecTraits_TIiElb 0x16f)[0x55fb1ca5952f]
/usr/bin/searchd(_ZNK15Expr_GetField_c16StringEvalPackedERK9CSphMatch 0xb7)[0x55fb1ca10587]
/usr/bin/searchd( 0x26b533)[0x55fb1c7a3533]
/usr/bin/searchd(_Z18MinimizeAggrResultR12AggrResult_tRK9CSphQuerybRKN3sph9StringSetEP16CSphQueryProfilePK18CSphFilterSettingsbbR12VecRefPtrs_tIP11AgentConn_tE 0xdba)[0x55fb1c7b13aa]
/usr/bin/searchd(_ZN15SearchHandler_c9RunSubsetEii 0xb6a)[0x55fb1c7b263a]
/usr/bin/searchd(_ZN15SearchHandler_c10RunQueriesEv 0x9e)[0x55fb1c7b333e]
/usr/bin/searchd(_Z19HandleCommandSearchR20CachedOutputBuffer_ctR13InputBuffer_cRN7Threads9ThdDesc_tE 0x2f8)[0x55fb1c7b3728]
/usr/bin/searchd(_Z16LoopClientSphinx16SearchdCommand_etiRN7Threads9ThdDesc_tER13InputBuffer_cR20CachedOutputBuffer_cb 0x341)[0x55fb1c7bd261]
/usr/bin/searchd( 0x28562d)[0x55fb1c7bd62d]
/usr/bin/searchd(_Z17HandlerThreadFuncPv 0x19)[0x55fb1c7be3b9]
/usr/bin/searchd(_ZN16SphCrashLogger_c13ThreadWrapperEPv 0x40)[0x55fb1c76d940]
/usr/bin/searchd(_Z20sphThreadProcWrapperPv 0x33)[0x55fb1c910853]
/lib/x86_64-linux-gnu/libpthread.so.0( 0x76db)[0x7f43b5eaf6db]
/lib/x86_64-linux-gnu/libc.so.6(clone 0x3f)[0x7f43b451b88f]
-------------- backtrace ends here ---------------
Please, create a bug report in our bug tracker (https://github.com/manticoresoftware/manticore/issues)
and attach there:
a) searchd log, b) searchd binary, c) searchd symbols.
Look into the chapter 'Reporting bugs' in the documentation
(http://docs.manticoresearch.com/latest/html/reporting_bugs.html)
Dump with GDB via watchdog
[Thu Mar 26 09:30:36.317 2020] [67061] watchdog: got USR1, performing dump of child's stack
Will run gdb on '/usr/bin/searchd', pid '67062'
--- 4 active threads ---
thd 0, proto sphinxapi, state query, command search
thd 1, proto sphinxql, state net_idle, command replace
thd 2, proto sphinxql, state net_idle, command replace
thd 3, proto sphinxql, state net_idle, command replace
------- CRASH DUMP END -------
[Thu Mar 26 09:30:39.579 2020] [67061] watchdog: main process 67062 crashed via CRASH_EXIT (exit code 2), will be restarted
[Thu Mar 26 09:30:39.579 2020] [67061] watchdog: got error 10, No child processes
[Thu Mar 26 09:30:39.579 2020] [67061] watchdog: main process 108612 forked ok
The text was updated successfully, but these errors were encountered: