OpenBazaar-Server crashes after submitting form to "Complete Order"

Question

OpenBazaar-Server crashes after submitting form to "Complete Order"

zmingee opened this issue 8 years ago · comments

Brief Description: When completing an order/contract, after filling out the review and such, when I click "Save", the server immediately crashes. Upon restarting the server, the contract is still waiting to be completed.

Operating System (OS and version):

(venv) [centos@cjqzmossvzok OpenBazaar-Server]$ cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

(venv) [centos@cjqzmossvzok OpenBazaar-Server]$ cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

(venv) [centos@cjqzmossvzok OpenBazaar-Server]$ uname -a
Linux cjqzmossvzok.localdomain 3.10.0-327.28.2.el7.x86_64 #1 SMP Wed Aug 3 11:11:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

OpenBazaar version:

(venv) [centos@cjqzmossvzok OpenBazaar-Server]$ git rev-parse HEAD
681ce3458b757128996ae5dbbefc175137c6aa48

Hardware: Virtualized

(venv) [centos@cjqzmossvzok OpenBazaar-Server]$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Model name:            Westmere E56xx/L56xx/X56xx (Nehalem-C)
Stepping:              1
CPU MHz:               2393.998
BogoMIPS:              4787.99
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0

Reproducible (Always / Almost Always / Sometimes / Rarely / Couldn't Reproduce): Always

Steps to reproduce:

Have a contract ready to "complete"
Click "Complete Order"
Fill in "Review section" and select stars
Click "Save"
Server crashes.

Observed Behavior: Instant crash on server side.

Expected Behavior: This is my first contract to complete, but I would imagine that it's supposed to go to the next "completed" stage.

Additional info (links, images, etc go here):
Last few lings of logs prior to crash

2016-09-04 18:51:13+0000 [KademliaProtocol] [DEBUG] calling remote function find_value on (u'46.101.196.124', 18467) (msgid y8zLQUGXHIdxD7bQiHLH8HBHy3I=)
2016-09-04 18:51:13+0000 [KademliaProtocol] [DEBUG] calling remote function find_value on (u'85.5.69.12', 1028) (msgid hs1G4ZlvGFlJQQCji3dgPdi9KjI=)
2016-09-04 18:51:13+0000 [KademliaProtocol] [DEBUG] calling remote function find_value on (u'128.199.37.235', 11113) (msgid o5DdjWg6OaHc7v6zBoMhicKypnE=)
2016-09-04 18:51:14+0000 [ConnHandler] [INFO] connected to 46.101.196.124:18467
2016-09-04 18:51:14+0000 [ConnHandler] [INFO] connected to 85.5.69.12:1028
2016-09-04 18:51:14+0000 [ConnHandler] [INFO] connected to 128.199.37.235:11113
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] received response for message id o5DdjWg6OaHc7v6zBoMhicKypnE= from 128.199.37.235:11113
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] call response from new node, transferring key/values
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] received response for message id y8zLQUGXHIdxD7bQiHLH8HBHy3I= from 46.101.196.124:18467
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] call response from new node, transferring key/values
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] received response for message id hs1G4ZlvGFlJQQCji3dgPdi9KjI= from 85.5.69.12:1028
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] call response from new node, transferring key/values
2016-09-04 18:51:14+0000 [ValueSpiderCrawl] [DEBUG] crawling with nearest: ([841287936961107144509883453235423856411681517846L, u'88.13.55.30', 34754], [842547717948697875400869613308209203349975503916L, u'151.80.205.158', 2141], [842281513778446541596603178768003348908324189270L, u'46.105.170.27', 18467], [844054606199116149186975481128152293954331821529L, u'52.201.232.177', 18467], [824167255903096399730944383771762891789978620438L, u'95.183.53.195', 31014], [866741835114263732371903052458189165981745567371L, u'151.80.205.158', 2193], [859027784560718287107225462566740029091628665389L, u'198.199.65.236', 18467], [858904505025065011187633376197253313665632890802L, u'92.129.156.203', 18467], [861985225556401480405207156482122853338108615595L, u'188.166.238.72', 59587], [851430262653653059404009170003321411744813207476L, u'188.166.40.235', 54638], [852166094615034737241333924740748284050631584267L, u'107.191.37.198', 18467], [845357424965952186486362305960731633555052918903L, u'103.193.4.135', 18467], [847089611816687390058618576867553586647870414642L, u'51.255.37.129', 18467], [847988956533089096469430629860777741045267758331L, u'54.93.54.140', 18467], [875513674665697600608980494126607811186362882844L, u'192.241.240.222', 18467], [872701618603688464371531803867322731786780518230L, u'46.101.196.124', 18467], [907071090450404451134232185730987645088125409168L, u'91.64.162.69', 62740], [896978667885778644556403547352817869374118739763L, u'87.113.234.80', 18467], [899319743874434219293219405717268109445182872794L, u'85.5.69.12', 1028], [895061327400247154078751315539329520537990608774L, u'137.74.118.40', 18467])
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] calling remote function find_value on (u'91.64.162.69', 62740) (msgid nib5cFIalu6DVMSsLbTS58Nh6J4=)
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] sending hole punch message to 91.64.162.69:62740
2016-09-04 18:51:14+0000 [ConnHandler] [INFO] connected to 91.64.162.69:62740
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] received response for message id nib5cFIalu6DVMSsLbTS58Nh6J4= from 91.64.162.69:62740
2016-09-04 18:51:14+0000 [KademliaProtocol] [DEBUG] call response from new node, transferring key/values
2016-09-04 18:51:15+0000 [KademliaProtocol] [DEBUG] received request from 46.101.196.124:18467, command INV
2016-09-04 18:51:15+0000 [KademliaProtocol] [DEBUG] sending response for msg id NMRffINTOjOiRVBLBjrMf6u96ZU= to 46.101.196.124:18467
2016-09-04 18:51:15+0000 [KademliaProtocol] [DEBUG] received request from 46.101.196.124:18467, command VALUES
2016-09-04 18:51:15+0000 [KademliaProtocol] [DEBUG] sending response for msg id MYZ03v6CJYGFyTc8xPasathYnZs= to 46.101.196.124:18467
2016-09-04 18:51:15+0000 [KademliaProtocol] [DEBUG] received request from 91.64.162.69:62740, command INV
2016-09-04 18:51:15+0000 [KademliaProtocol] [DEBUG] sending response for msg id VZiqkJw1s3oegVSpk4YT5D74ZdI= to 91.64.162.69:62740
2016-09-04 18:51:16+0000 [KademliaProtocol] [DEBUG] received request from 91.64.162.69:62740, command VALUES
2016-09-04 18:51:16+0000 [KademliaProtocol] [DEBUG] sending response for msg id stVqfXLgqJq+wyauqtIpuhe/pCY= to 91.64.162.69:62740
Segmentation fault
(venv) [centos@cjqzmossvzok OpenBazaar-Server]$

Zane Mingee · Answer 1 · Mon Sep 05 2016 03:06:58 GMT+0800 (China Standard Time)

Also, for what it's worth. I just completed an order on the local desktop app (bought a sticker from OB1) and it worked fine. Application did not crash. I'm guessing this is limited to the server.

Deleted user · Answer 2 · Mon Sep 05 2016 04:52:01 GMT+0800 (China Standard Time)

howdy there, i'm the seller here. I had to restore a backup a while ago and I have made sales since then without a hitch. Every error I get seems to be a version of http://pastebin.com/uVUA9bxf

SamPatt · Answer 3 · Sat Sep 17 2016 02:18:50 GMT+0800 (China Standard Time)

@zmingee We're taking a look now, sorry for late response.

Zane Mingee · Answer 4 · Fri Oct 21 2016 00:02:42 GMT+0800 (China Standard Time)

@SamPatt I just wanted to follow up on this bug report. It's been over a month now and the seller still hasn't gotten paid.

I've tried everything I can think of: I've updated and reinstalled all the dependencies on my side, updated OpenBazaar-Server (from master branch), resized the VM from 1c1g to 2c4g just in case it was memory related, etc., and I still get the same error. At this point I'm not sure if it's on my end or the seller's end.

Deleted user · Answer 5 · Fri Oct 21 2016 01:35:47 GMT+0800 (China Standard Time)

@zmingee I'm very sure the problem is on my end. I took some notes about the source code and what could have gone wrong, but I'm not at home

EDIT: I didn't know he had a segfault on his end. It might be both?

Brian Hoffman · Answer 6 · Mon Dec 26 2016 08:10:17 GMT+0800 (China Standard Time)

Will have to return to this this week.

Deleted user · Answer 7 · Mon Dec 26 2016 08:11:24 GMT+0800 (China Standard Time)

Thanks, no rush, and merry christmas