View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002741 | SkyChart | 1-Software | public | 24-06-16 09:42 | 24-06-19 10:57 |
| Reporter | oldherl | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | PC | OS | Linux | OS Version | 64bit |
| Product Version | 4.3 beta | ||||
| Summary | 0002741: Can't update GRS position from JUPOS project | ||||
| Description | Can't update GRS position by the "Get the recent GRS measurement from JUPOS project." button. | ||||
| Steps To Reproduce | Click the "Get the recent GRS measurement from JUPOS project." button in the solar system settings dialog. Nothing happens. No download dialog appears. GRS position doesn't update. | ||||
| Tags | Solar System | ||||
|
|
For me it work, but this button do not show any dialog and the data where last updated in October 2023. If the date above the button is 2023.10.01 you are up to date. There is no new observation since May because of the solar conjunction, so I wait a few more month to update the data. This has no implication on the precision of the GRS position because the program take account for the mean GRS drift. |
|
|
No, it shows 2019.08.12. And if I change the longitude to 0 for example, and then click the "Get the recent GRS measurement from JUPOS project." button, it doesn't change. I suspect that I might have an old format of some file. Could you tell me in which file under ~/.skychart the longitude stores? |
|
|
Can you try if you can open this file in your web browser: https://www.ap-i.net/pub/virtualplanet/grs.txt The program download this file to ~/.skychart/tmp/grs.txt , can you to look at this file if it contain the 2023 date. From the web server log I see you update the leap seconds file then the grs file a few minutes before you post your response here. For the web server side both where successful with a http response 200. Because this is a very small and trivial download the program do not show a message in case of error. I will add one so we better know with it fail. |
|
|
Yes I can access that URL with my browser. There is no grs.txt file in my ~/.skychart/tmp folder. I tried to create an empty one and click the button but still nothing happens. |
|
|
Please install the version 4.3-4855 from https://vega.ap-i.net/tmp/skychart/ Then retry, it must show an error message. |
|
|
Hello. I'm using gdb to debug the 4.3-4852 version. Here's the output: Thread 19 "skychart" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd1e006c0 (LWP 2515052)] 0x00007ffff5e7b24e in ossl_tls_handle_rlayer_return (s=s@entry=0x7fffa0015350, writing=writing@entry=0, ret=-2, file=file@entry=0x7ffff5eb9157 "ssl/record/rec_layer_s3.c", line=line@entry=687) at ssl/record/rec_layer_s3.c:521 Downloading source file /usr/src/debug/openssl/openssl-3.3.1/ssl/record/rec_layer_s3.c 521 int al = s->rlayer.rrlmethod->get_alert_code(s->rlayer.rrl); (gdb) bt #0 0x00007ffff5e7b24e in ossl_tls_handle_rlayer_return (s=s@entry=0x7fffa0015350, writing=writing@entry=0, ret=-2, file=file@entry=0x7ffff5eb9157 "ssl/record/rec_layer_s3.c", line=line@entry=687) at ssl/record/rec_layer_s3.c:521 #1 0x00007ffff5e7ce67 in ssl3_read_bytes (ssl=<optimized out>, type=22 '\026', recvd_type=0x7fffd1dff358 "", buf=0x7fffa001c2f0 "p\234\001\240\377\177", len=4, peek=0, readbytes=0x7fffd1dff370) at ssl/record/rec_layer_s3.c:687 #2 0x00007ffff5e98a0a in tls_get_message_header (s=0x7fffa0015350, mt=<synthetic pointer>) at ssl/statem/statem_lib.c:1539 #3 read_state_machine (s=0x7fffa0015350) at ssl/statem/statem.c:624 #4 0x00007ffff5e9341e in state_machine (s=0x7fffa0015350, server=0) at ssl/statem/statem.c:478 #5 0x0000000000e68a94 in SSLCONNECT (SSL=0x7fffa0015350) at ssl_openssl_lib.pas:1348 #6 0x0000000000e552aa in CONNECT (this=0x7ffff26c7340) at ssl_openssl.pas:545 #7 0x0000000000e4848f in SSLDOCONNECT (this=0x7fffb389a450) at blcksock.pas:3972 #8 0x0000000000e4a1aa in INTERNALDOCONNECT (this=0x7fffbc567e40, NEEDSSL=true) at httpsend.pas:395 #9 0x0000000000e4a249 in INTERNALCONNECT (this=0x7fffbc567e40, NEEDSSL=true) at httpsend.pas:408 #10 0x0000000000e4b2cf in HTTPMETHOD (this=0x7fffbc567e40, METHOD=0x11b7fd8 "GET", URL=0x112cc20 "https://www.ap-i.net/pub/virtualplanet/grs.txt") at httpsend.pas:546 #11 0x0000000000dd4f5e in EXECUTE (this=0x7ffff26c6f40) at downloaddialog.pas:793 #12 0x0000000000487798 in ?? () #13 0x00007ffff26c6f40 in ?? () #14 0x00007fffbe918000 in ?? () #15 0x00007ffff26c6f40 in ?? () #16 0x000000000043e0ec in SYSTEM_$$_SYSFREEMEM_FIXED$PFREELISTS$PMEMCHUNK_FIXED$$QWORD () #17 0x00007fffd1dffb98 in ?? () #18 0x0000000000000000 in ?? () (gdb) print s $1 = (SSL_CONNECTION *) 0x7fffa0015350 (gdb) print s->rlayer $2 = {s = 0x7fffa0015350, custom_rlmethod = 0x0, rlarg = 0x0, rrlmethod = 0x0, wrlmethod = 0x0, rrl = 0x0, wrl = 0x0, rrlnext = 0x0, default_read_buf_len = 0, read_ahead = 0, wnum = 0, handshake_fragment = "\000\000\000", handshake_fragment_len = 0, wpend_tot = 0, wpend_type = 0 '\000', wpend_buf = 0x0, alert_count = 0, d = 0x0, record_padding_cb = 0x0, record_padding_arg = 0x0, block_padding = 0, num_recs = 0, curr_rec = 0, tlsrecs = {{ rechandle = 0x0, version = 0, type = 0 '\000', data = 0x0, allocdata = 0x0, length = 0, off = 0, epoch = 0, seq_num = "\000\000\000\000\000\000\000"} <repeats 32 times>}} (gdb) print s->rlayer.rrlmethod $3 = (const OSSL_RECORD_METHOD *) 0x0 Hope it's useful. |
|
|
So the crash is in your openssl library. Which distribution do you use to have openssl 3.3.1 ? Stable Debian and Ubuntu are 3.0, last Fedora is 3.2, and both work. |
|
|
Arch Linux. I found there's some changes in the upstream synapse library about libssl3, but I don't know how to update it. Can you advise me on that? I'm a programmer but have no knowledge of how to build a FreePascal library. |
|
|
I'm building skychart from your Github source so if you make a new branch, I would be able to build it and test. |
|
|
Thank you for the information, I update the synapse library with the new openssl3 unit. It work fine with my Ubuntu, I will make more testing on Windows and Mac but it must be OK because I provide the openssl 3.0 libraries. You can test it now, I commit the change to the main branch. |
|
|
No luck. It's still crashing at the same place. I reverted the b9a708526dc92985665cac53967442df47e1237f commit (error message box) to get the callstack: 0x00007ffff5e7b24e in ossl_tls_handle_rlayer_return (s=s@entry=0x7fffa807bdc0, writing=writing@entry=0, ret=-2, file=file@entry=0x7ffff5eb9157 "ssl/record/rec_layer_s3.c", line=line@entry=687) at ssl/record/rec_layer_s3.c:521 521 int al = s->rlayer.rrlmethod->get_alert_code(s->rlayer.rrl); (gdb) bt #0 0x00007ffff5e7b24e in ossl_tls_handle_rlayer_return (s=s@entry=0x7fffa807bdc0, writing=writing@entry=0, ret=-2, file=file@entry=0x7ffff5eb9157 "ssl/record/rec_layer_s3.c", line=line@entry=687) at ssl/record/rec_layer_s3.c:521 #1 0x00007ffff5e7ce67 in ssl3_read_bytes (ssl=<optimized out>, type=22 '\026', recvd_type=0x7fffd27ff358 "\360\342\a\250\377\177", buf=0x7fffa806f2c0 "\260\021\t\250\377\177", len=4, peek=0, readbytes=0x7fffd27ff370) at ssl/record/rec_layer_s3.c:687 #2 0x00007ffff5e98a0a in tls_get_message_header (s=0x7fffa807bdc0, mt=<synthetic pointer>) at ssl/statem/statem_lib.c:1539 #3 read_state_machine (s=0x7fffa807bdc0) at ssl/statem/statem.c:624 #4 0x00007ffff5e9341e in state_machine (s=0x7fffa807bdc0, server=0) at ssl/statem/statem.c:478 #5 0x0000000000e68ac4 in SSLCONNECT (SSL=0x7fffa807bdc0) at ssl_openssl3_lib.pas:736 #6 0x0000000000e55459 in CONNECT (this=0x7ffff26c7340) at ssl_openssl3.pas:516 #7 0x0000000000e4857f in SSLDOCONNECT (this=0x7fffb3857390) at blcksock.pas:3972 #8 0x0000000000e4a29a in INTERNALDOCONNECT (this=0x7fffbc567e40, NEEDSSL=true) at httpsend.pas:395 #9 0x0000000000e4a339 in INTERNALCONNECT (this=0x7fffbc567e40, NEEDSSL=true) at httpsend.pas:408 #10 0x0000000000e4b3bf in HTTPMETHOD (this=0x7fffbc567e40, METHOD=0x11b8078 "GET", URL=0x112ccc0 "https://www.ap-i.net/pub/virtualplanet/grs.txt") at httpsend.pas:546 #11 0x0000000000dd504e in EXECUTE (this=0x7ffff26c6f40) at downloaddialog.pas:793 #12 0x0000000000487798 in ?? () #13 0x00007ffff26c6f40 in ?? () #14 0x00007fffbe118000 in ?? () #15 0x00007ffff26c6f40 in ?? () #16 0x000000000043e0ec in SYSTEM_$$_SYSFREEMEM_FIXED$PFREELISTS$PMEMCHUNK_FIXED$$QWORD () #17 0x00007fffd27ffb98 in ?? () #18 0x0000000000000000 in ?? () |
|
|
I compile openssl 3.3.1 to test with my system and everything work fine. Do you know if your openssl is compiled with some specific options? |
|
|
Arch Linux package of openssl is built with this PKGBUILD file: https://gitlab.archlinux.org/archlinux/packaging/packages/openssl/-/blob/main/PKGBUILD with compiler flags (CFLAGS etc) from this makepkg.conf file: https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/blob/main/makepkg.conf |
|
|
When I use LD_LIBRARY_PATH to load the Debian Experimental build of openssl (libssl3t64) from https://packages.debian.org/experimental/amd64/libssl3t64/download , it still crashes at the same place. Could you please share the build script and/or the binaries of your openssl 3.3.1 build? |
|
|
You can also use LD_LIBRARY_PATH to try the binary package from https://archlinux.org/packages/core/x86_64/openssl/download/ to test if it crashes. |
|
|
For me all this versions work: - rebuild with the option from Arch - extract the Debian experimental package - extract the Arch package Each time I check the right library are loaded using lsof, for example: lsof -p 154305 | grep -e libssl -e libcrypto skychart 154305 pch mem REG 8,3 5026736 20241954 /home/pch/download/openssl-3.3.1-1-x86_64.pkg/usr/lib/libcrypto.so.3 skychart 154305 pch mem REG 8,3 888632 20241956 /home/pch/download/openssl-3.3.1-1-x86_64.pkg/usr/lib/libssl.so.3 So there is something else with your system. Do you try the other entries in the Update menu, for example "Artificial satellites", to see if this is specific to this host and file. |
|
|
https://celestrak.org/NORAD/elements/visual.txt Resolving celestrak.org:443 Connect celestrak.org:443 Request sent, waiting response Resolving celestrak.org:443 Connect celestrak.org:443 Request sent, waiting response Read KB: 16.0 of 26.4 (60.57%), 2.7 KB/Seconds Read KB: 26.4 of 26.4 (100.00%) Finished: Read KB: 26.4 of 26.4 (100.00%) https://www.mmccants.org/programs/qsmag.zip Resolving www.mmccants.org:443 Connect www.mmccants.org:443 Request sent, waiting response Resolving www.mmccants.org:443 Connect www.mmccants.org:443 Request sent, waiting response Read KB: 40.9 of 89.1 (45.93%), 32.2 KB/Seconds Read KB: 89.1 of 89.1 (100.00%) Finished: Read KB: 89.1 of 89.1 (100.00%) No problem. |
|
|
OK, so SSL work for this sites. www.mmccants.org also use a Let's Encrypt certificate, like my site www.ap-i.net, this is not a certificate chain issue. I check both using https://www.ssllabs.com/ssltest , the only obvious difference is my server do not support the old TLS 1.0 and 1.1, it is better rated for that. For another test from my server, can you use Update / DeltaT recent value. It not show any window but "Updated successfully" after a few seconds. The check in ~.skychart/ you have new files : leap-seconds.list finals.data deltat.txt |
|
|
Yes, it works and I can find those files. And they do show the old "Download File" window with the progress bar. |
|
|
I remark a possible problem now, the GRS download do not use the proxy setting in menu Setup / Update / Proxy. Do you have a proxy setup here? |
|
|
I noticed the same thing earlier in the code. But I don't use a proxy. |
|
|
I find the reason for this error, this is because I do the GRS update first for the Virtual Planet Atlas software that not have proxy setting. Then I copy the function to Skychart but forget to change for the downloader object that use the proxy. This is fixed by : https://github.com/pchev/skychart/commit/6d49873101de3c601de56e0dc2e611aa4970a320 Can you try with this version? |
|
|
If this still not work, can you try to remove the line 1094 " DownloadDialog1.QuickCancel := True;" in fu_config_solsys.pas |
|
|
After removing line 1094 it works now! Thank you. However if I use gdb to start skychart, on startup there is a segfault: Thread 17 "skychart" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd28006c0 (LWP 2584706)] 0x0000000000e41820 in CONNECT (this=0x7fffd0add250, IP=0x7fffd01383d8 'www.ap-i.net', PORT=0x11d5c58 '443') at blcksock.pas:1962 1962 SockCheck(synsock.Connect(FSocket, Sin)); (gdb) bt #0 0x0000000000e41820 in CONNECT (this=0x7fffd0add250, IP=0x7fffd01383d8 'www.ap-i.net', PORT=0x11d5c58 '443') at blcksock.pas:1962 #1 0x0000000000e48389 in CONNECT (this=0x7fffd0add250, IP=0x7fffd01383d8 'www.ap-i.net', PORT=0x11d5c58 '443') at blcksock.pas:3910 #2 0x0000000000e4a702 in INTERNALDOCONNECT (this=0x7fffd0a895a0, NEEDSSL=true) at httpsend.pas:388 #3 0x0000000000e4a809 in INTERNALCONNECT (this=0x7fffd0a895a0, NEEDSSL=true) at httpsend.pas:408 #4 0x0000000000e4b88f in HTTPMETHOD (this=0x7fffd0a895a0, METHOD=0x11b80e8 'GET', URL=0x1127448 'https://www.ap-i.net/pub/skychart/deltat/leap-seconds.list') at httpsend.pas:546 #5 0x0000000000dd551e in EXECUTE (this=0x7ffff26c2e40) at downloaddialog.pas:800 #6 0x0000000000487798 in ?? () #7 0x00007ffff26c2e40 in ?? () #8 0x00007fffd0138000 in ?? () #9 0x00007ffff26c2e40 in ?? () #10 0x000000000043e0ec in SYSTEM_$$_SYSFREEMEM_FIXED$PFREELISTS$PMEMCHUNK_FIXED$$QWORD () #11 0x00007fffd27ffb98 in ?? () #12 0x0000000000000000 in ?? () After ignoring this (press c) the application works without error. Is there some similar problems about downloading leap-seconds on startup? As I mentioned, updating leap-seconds using the menu is OK. |
|
|
Yes the leap second download on startup use this QuickCancel option. This is to not block the program startup when the leap second file is outdated but there is issue with the network connection. In this case there is a two seconds delay after what the download is canceled, to allow the program to continue. This destroy the socket object and explain why it crash. It is expected that in this case all the exception are ignored. If QuickCancel is False, after two seconds it show the download window with the progress and a button to manually cancel. I will change line 1094 because there is no reason to do this cancel automatically when the download is requested by the user, even the file is very small. It look like your network connection initialization is very slow as after 2 seconds it is still in the connection process, maybe slow DNS resolution? |
|
|
No, it's not a slow DNS. I live far away from Europe and the >2sec delay is normal. Even a simple ICMP ping to vega.ap-i.net is about 300-400ms from here! Now everything is clear. All those crashes are made by terminated connection. 1. The purpose of QuickCancel is questionable. I recently read some interesting thought of a person working in Antarctica https://brr.fyi/posts/engineering-for-slow-internet . It turned out that a lot of "modern" internet infrastructure are not well prepared for remote places and/or low quality links. I hope skychart could be better than them, given the nature of remoteness of observation locations. If the link is slow, let it work slowly. Don't give up because a following re-try would also be given up and nothing would work. 2. It also answers a long lasting mystery in my heart: why skychart looks "so slow" about downloading? The 2-second delay from clicking the download button to the appearance of the progress bar window is misleading. I (and most users I believe) thought the program was stuck after clicking the button, and only started to download when the dialog shows! I just tried to modify it to show the progress bar window immediately as the downloading starts, and it looks super responsive now. That should be the default behavior. 3. I don't understand why the leap-seconds file needs to be downloaded on startup. Leap seconds are not happening that frequently. Once per month or so should be sufficient, or even just don't download automatically. Give a prompt to the user if it's too old and do the update from the menu bar. But this is not very relevant to the GRS crash thing and I can open a separate issue if you think that more discussion is needed. Thanks for this long and windy debugging again! |
|
|
I make a change to update the leap second file on startup in a separate thread without blocking the program. This way it can take all the time necessary for this update. You can try that from the last master branch. To test, delete the file ~/.skychart/leap-seconds.list to force an update. The update is not on every startup, only if the file expiration date is less than one month from now. The file is generally updated two time a year with a 6 month validity so the update occur only once every 6 month. But sure if the update always fail it try on every startup. The QuickCancel option is no more used anywhere and I remove it. But I keep the 2 second delay to show the download window, this is to prevent a flashing window for the small download that are generally complete in less than 0.5 seconds. Only DeltaT, GRS and program update do not show anything in this case, the other download show progress in a message list. |
|
|
It's fixed. This issue could be closed now. |
|
|
Thank you for your help improving that. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 24-06-16 09:42 | oldherl | New Issue | |
| 24-06-16 09:42 | oldherl | Tag Attached: Solar System | |
| 24-06-16 16:14 | Patrick Chevalley | Status | new => feedback |
| 24-06-16 16:14 | Patrick Chevalley | Note Added: 0008913 | |
| 24-06-17 08:00 | oldherl | Note Added: 0008915 | |
| 24-06-17 08:00 | oldherl | Status | feedback => new |
| 24-06-17 09:42 | Patrick Chevalley | Note Added: 0008916 | |
| 24-06-17 12:39 | oldherl | Note Added: 0008917 | |
| 24-06-17 13:30 | Patrick Chevalley | Note Added: 0008918 | |
| 24-06-17 13:39 | oldherl | Note Added: 0008919 | |
| 24-06-17 14:11 | Patrick Chevalley | Note Added: 0008920 | |
| 24-06-17 14:15 | oldherl | Note Added: 0008921 | |
| 24-06-17 14:17 | oldherl | Note Added: 0008922 | |
| 24-06-17 14:48 | Patrick Chevalley | Note Added: 0008923 | |
| 24-06-17 15:03 | oldherl | Note Added: 0008924 | |
| 24-06-17 16:11 | Patrick Chevalley | Note Added: 0008925 | |
| 24-06-17 16:18 | oldherl | Note Added: 0008926 | |
| 24-06-17 16:38 | oldherl | Note Added: 0008927 | |
| 24-06-17 16:46 | oldherl | Note Added: 0008928 | |
| 24-06-17 17:04 | Patrick Chevalley | Note Added: 0008929 | |
| 24-06-17 17:09 | oldherl | Note Added: 0008930 | |
| 24-06-17 17:50 | Patrick Chevalley | Note Added: 0008931 | |
| 24-06-17 17:56 | oldherl | Note Added: 0008932 | |
| 24-06-17 18:10 | Patrick Chevalley | Note Added: 0008933 | |
| 24-06-17 18:14 | oldherl | Note Added: 0008934 | |
| 24-06-17 18:23 | Patrick Chevalley | Note Added: 0008935 | |
| 24-06-17 18:30 | Patrick Chevalley | Note Added: 0008936 | |
| 24-06-17 18:49 | oldherl | Note Added: 0008937 | |
| 24-06-17 20:08 | Patrick Chevalley | Note Added: 0008938 | |
| 24-06-18 03:38 | oldherl | Note Added: 0008939 | |
| 24-06-18 16:25 | Patrick Chevalley | Note Added: 0008940 | |
| 24-06-19 03:03 | oldherl | Note Added: 0008941 | |
| 24-06-19 10:57 | Patrick Chevalley | Status | new => resolved |
| 24-06-19 10:57 | Patrick Chevalley | Resolution | open => fixed |
| 24-06-19 10:57 | Patrick Chevalley | Note Added: 0008942 |
