Opened 4 years ago

Closed 4 years ago

#16030 closed defect (fixed)

Visual Studio 2013 Test Problems

Reported by: NewEraCracker Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version: Tor: 0.2.6.7
Severity: Keywords: tor-relay, msvc, lorax
Cc: Actual Points:
Parent ID: #13081 Points:
Reviewer: Sponsor:

Description

I've built Tor using the patch tor-0.2.6.7-msvs2013-build.diff​ (29/04/2015 20:18:15) posted at #13081 with mingw32 and MSVC2013.

Build with mingw32 goes fine. Tests go fine.

Build with MSVC2013 goes "fine" with some warnings in both Release and Test configuration. There are 10 test failures. The fail of util/logging/sigsafe_err is expected as it was failing on 0.2.5.12 with MSVC2010 as far as I remember. The other 9 failures are quite bad as they result in crashes.

Attached are some build logs.

Child Tickets

Attachments (4)

mingw32-test-results.txt (12.9 KB) - added by NewEraCracker 4 years ago.
msvc2013_release_build_log.txt (24.5 KB) - added by NewEraCracker 4 years ago.
msvc2013_test_build_log.txt (39.5 KB) - added by NewEraCracker 4 years ago.
msvc2013_test_results.txt (15.7 KB) - added by NewEraCracker 4 years ago.

Download all attachments as: .zip

Change History (8)

Changed 4 years ago by NewEraCracker

Attachment: mingw32-test-results.txt added

Changed 4 years ago by NewEraCracker

Changed 4 years ago by NewEraCracker

Attachment: msvc2013_test_build_log.txt added

Changed 4 years ago by NewEraCracker

Attachment: msvc2013_test_results.txt added

comment:1 Changed 4 years ago by NewEraCracker

Component: - Select a componentTor
Keywords: tor-relay msvc lorax added
Version: Tor: 0.2.6.7

comment:2 Changed 4 years ago by nickm

A stack trace from one or two of those channel_get_canonical_remote_descr calls would be helpful.

It appears that something in the MSVC build is trying to call channel_get_canonical_remote_descr from inside the tests, which is failing because the channel here is really a fake channel set up by new_fake_channel() in test_channels.c . Either the bug is that the call is happening, or that we're not making it safe for that call to happen on a fake channel.

The warnings need one-by-one examination. Be especially careful about touching crypto stuff in src/ext.

comment:3 Changed 4 years ago by NewEraCracker

Doing this change makes all channel related tests pass:

--- a/src/test/test_channel.c
+++ b/src/test/test_channel.c
@@ -420,6 +420,7 @@
 
   chan->close = chan_test_close;
   chan->get_overhead_estimate = chan_test_get_overhead_estimate;
+  chan->get_remote_descr = chan_test_get_remote_descr;
   chan->num_bytes_queued = chan_test_num_bytes_queued;
   chan->num_cells_writeable = chan_test_num_cells_writeable;
   chan->write_cell = chan_test_write_cell;
@@ -615,7 +616,6 @@
   /* Test channel_dump_statistics */
   ch->describe_transport = chan_test_describe_transport;
   ch->dumpstats = chan_test_dumpstats;
-  ch->get_remote_descr = chan_test_get_remote_descr;
   ch->is_canonical = chan_test_is_canonical;
   old_count = test_dumpstats_calls;
   channel_dump_statistics(ch, LOG_DEBUG);

As now all fake channels will have a valid pointer to get_remote_descr. Yet I am not sure if this is the correct fix.

Getting a stack trace in Visual Studio is a pain. But I'll see if there is anything I can do.

comment:4 Changed 4 years ago by nickm

Resolution: fixed
Status: newclosed

Merged to 0.2.6 and master. Thanks!

Note: See TracTickets for help on using tickets.