Auction 262959197940: LIONEL # 6-5165 & 6-5166 072 RIGHT & LEFT HAND REMOTE SWITCHES LNIB ...L@@K!
Time remaining: 12 hours 13 mins 44 secs (44024 seconds)
End time: 07/05/2017 22:00:14
Segmentation fault (core dumped)
It did not create a bug report. This was caused by there being 0 bids on the item. I made an initial min bid and the problem went away. Also note that the time problem is not an issue
if one bids less than 24 hours from end time.
Sorry I have not written a C program that seg faults in years so I am not that familiar
with gdb and in fact can not find where my Centos 7 system might have written the "core"
file. That said it looks like it faults on any auction for which there are 0 bids.
For instance 192178953153
Of course the program cannot create a bug report on a segmentation fault.
Can you try to find out where esniper crashed? ("gdb esniper core", command "where")
Unfortunately I cannot debug the problem, because esniper doesn't segfault on my 64-bit Linux Mint system.
I just checked with auction 192178953153.
How exactly do you call esniper?
Did you specify ebay servers other than *.ebay.com?
The core file is normally created in the current working directory. (See "man core".)
OK I figured out how to get Centos 7 to generate a core dump and ran esniper under dgb
and this is what it says
[New Thread 0x7ffff33d1700 (LWP 17801)]
[Thread 0x7ffff33d1700 (LWP 17801) exited]
[New Thread 0x7ffff33d1700 (LWP 17803)]
[Thread 0x7ffff33d1700 (LWP 17803) exited]
[New Thread 0x7ffff33d1700 (LWP 17804)]
[Thread 0x7ffff33d1700 (LWP 17804) exited]
Auction 192178953153: Never opened 1994 Lionel 072 Remote Control Switches Instruction Booklet.
Time remaining: 4 hours 50 mins 0 secs (17400 seconds)
End time: 07/05/2017 21:29:33
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77f2c64 in ____strtod_l_internal () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install nss-softokn-3.16.2.3-9.el7.x86_64
nss-sysinit-3.19.1-3.el7_1.x86_64 sqlite-3.7.17-4.el7.x86_64
Bob
Bodo,
I just noticed that your time remaining is correct so you must be running the cvs version.
I am running the vanilla download of esniper-2-33-0. perhaps this problem has been fixed
in cvs even though I did not see a bug report relating to it.
Bob
Hello Bob,
I don't think the fix for the remaining time is related to the segfault. Without the fix it should simply ignore the days field of the remaining time.
Maybe you overlooked my questions: Did you specify ebay servers other than *.ebay.com? How exactly do you run esniper?
Especially the server question is important because ebay may use a different page structure.
I did not yet check the source, but I think function strtod() is used to read the bid amounts. So esniper seems to think it has found a bid and maybe tries to convert a NULL pointer.
It should check this and create a bug report in this case.
I don't know how much information the debugger can show without debug symbols, but please use the command "where" after the segfault to get a stack trace. This (hopefully) will show if my assumption is correct.
Bodo
Bodo,
I do not specify any ebay servers so it is going to whatever the default is for 2-33-0
my command is ./esniper -l logs try and try is quantity = 1 192178953153 8.99
I figured out how to get it to run under gdp and this is the output of the where after it
seg faults:
(gdb) where
0 0x00007ffff77f2c64 in ____strtod_l_internal () from /lib64/libc.so.6
1 0x000000000040751c in atof (__nptr=<optimized out="">)</optimized>
2 parseBidHistoryInternal (mp=mp@entry=0x61f200, aip=aip@entry=0x6141b0,
3 0x00000000004082db in parseBidHistory (mp=mp@entry=0x61f200,
4 0x0000000000403c50 in getInfoTiming (aip=0x6141b0,
5 0x0000000000404337 in getInfo (aip=<optimized out="">) at auction.c:244</optimized>
6 0x0000000000405d68 in sortAuctions (auctions=0x614190,
7 0x0000000000402028 in main (argc=<optimized out="">, argv=<optimized out="">)</optimized></optimized>
(gdb)
Bob
Related
Bugs:
#721Maybe it will help. CVS version.
(gdb) run /home/user/esniper/tektronix
Starting program: /usr/local/bin/esniper /home/user/esniper/tektronix
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3957700 (LWP 1848)]
[Thread 0x7ffff3957700 (LWP 1848) exited]
[New Thread 0x7ffff3957700 (LWP 1849)]
[Thread 0x7ffff3957700 (LWP 1849) exited]
[New Thread 0x7ffff3957700 (LWP 1850)]
[Thread 0x7ffff3957700 (LWP 1850) exited]
Auction 272659259790: Tektronix TDS 420A Four Channel Digitizing Oscilloscope 200 MHz 100 MS/s WW
Time remaining: 4 days 8 hours 42 mins 0 secs (376920 seconds)
End time: 12/05/2017 23:15:32
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77f98b4 in __GI_____strtod_l_internal (nptr=0x0, endptr=0x0, group=<optimized out="">, loc=0x7ffff7b62f20 <_nl_global_locale>) at strtod_l.c:600
600 strtod_l.c: No such file or directory.
(gdb) where</optimized>
0 0x00007ffff77f98b4 in __GI_____strtod_l_internal (nptr=0x0, endptr=0x0, group=<optimized out="">, loc=0x7ffff7b62f20 <_nl_global_locale>) at strtod_l.c:600</optimized>
1 0x0000000000409b28 in parseBidHistoryInternal (pp=0x6824c0, mp=0x682430, aip=0x6344d0, start=1494243212, debugMode=0) at history.c:619
2 0x0000000000407b38 in parseBidHistory (mp=0x682430, aip=0x6344d0, start=1494243212, timeToFirstByte=0x0, debugMode=0) at history.c:81
3 0x00000000004022c5 in getInfoTiming (aip=0x6344d0, timeToFirstByte=0x0) at auction.c:278
4 0x000000000040216c in getInfo (aip=0x6344d0) at auction.c:244
5 0x0000000000406360 in sortAuctions (auctions=0x617a10, numAuctions=2, quantity=0x7fffffffe4e4) at auctioninfo.c:485
6 0x000000000040797f in main (argc=1, argv=0x7fffffffe630) at esniper.c:864
(gdb)
Thank you. Now I know that I have to look at the atof() call at line 610 in (your version of) history.c.
Probably the value of "currently" is a NULL pointer and this is passed via fixupPrice() into atof() which is not allowed.
I don't know if you get a different HTML page from ebay or if there are versions of the library that don't segfault when NULL is passed into atof().
I will fix this. (Maybe esniper will then create a bug report, but this will save the HTML page.)
Bug in history.c at line 396
if (memStr(mp, "Total Bids:")) {
Ebay changed bid history.
Edit text from "Total Bids:" to "Bids:"
Its fix problem with segfault.
I've experienced similar (easily reproducible) SEGFAULT on latest revision in CVS and patch suggested by Dmitrij somewhat fixed the problem though IMHO there should be a safeguard against segfaults when string is not found (or does not match) with graceful error message. Patch is below:
I have committed the suggested fix of Dmitrij to the CVS repository.
I committed a fix for the NULL pointer problem. Instead of feeding the result from priceFixup() directly into atof() it is checked for NULL pointer. In this case the resulting price will be set to -1 to indicate an error.
Had this problem the other day, didn't think to pull the CVS version. However, some thoughts after running through lldb.
The problem seems to be tied to either a change in page format, or a flaw in logic related to page format. Looking at the comments in history.c, I suspect the former. Line numbers refer to version 2.3.3 release.
At line 513 of history.c just prior to crashing, I had 3 columns, but the number of bids was "No bids have been placed". There is explicit handling for this case, but only where there are two columns, rather than three, the controlling case statement thus skips all the logic handling the no bid case, tries to use atof on "No bids have been placed", and passes the resulting NULL off for handling, resulting in crash and burn.
Relying on the number of columns to determine the use case seems extremely fragile to me.
Last edit: Simon Stapleton 2017-07-19
Your post refer revision 1.28. There has been done some changes since then. Please use the actual revision 1.33.
You’re still gonna have the same underlying problem. The “No bids have been placed” case has 3 columns, but handling for that case in CVS HEAD assumes there are only 2. Any fixes stopping the segfault aren’t going to solve the flaw in the logic. Or indeed, help with an enormously fragile approach. It may be the case that counting columns is the only way to decide which case we’re in, but I strongly doubt it.
Cheers, and thanks for a very useful tool
Simon
Could you please attach the html source of the page you get. I cannot reproduce this error at the moment.
edit: CVS version fixed it for me
Last edit: Pavel Gorovtsev 2017-10-07