how do we see the detailed hashing process like Version 1.0 does?

[Suitear]

When I use the 1.0 version, the -v mode can show the hashing process like this

128 of 300 pieces

so how can we get that back in 1.1?

Thanks.

[pobrn]

When mktorrent is built with the USE_PTHREADS option, then it'll print the progress. Otherwise it won't, and as far as I can tell, this has always been the case. Did you build it yourself or are you using a distribution package?

[Suitear]

When mktorrent is built with the USE_PTHREADS option, then it'll print the progress. Otherwise it won't, and as far as I can tell, this has always been the case. Did you build it yourself or are you using a distribution package?

Thanks, but when I tried to use the recommended option make USE_PTHREADS=1 USE_OPENSSL=1 USE_LONG_OPTIONS=1 to make and make install, the process is successful.

the following error shows up when I try to make a torrent. Segmentation fault

[pobrn]

Does that still happen if you run it directly from the directory without installation? Can you try

make clean
make CFLAGS="-Og -ggdb3" USE_PTHREADS=1 USE_OPENSSL=1 USE_LONG_OPTIONS=1
gdb --args ./mktorrent <problematic file/directory>

then when you see the (gdb) prompt, type

handle all nostop
handle SIGSEGV stop
r

when you see something like

Thread X "mktorrent" received signal SIGSEGV, .....

type bt, enter, then copy and paste the output, after that you can exit by typing q.

[Suitear]

BTW, I use the default make and make install option, it's fine to create torrent.

Thanks, bro. This works. But the gdb package was not installed before. The output is as follows.

Thread 4 "mktorrent" received signal SIG32, Real-time event 32. [Thread 0x7ffff72e8700 (LWP 31577) exited] [Thread 0x7ffff7ae9700 (LWP 31576) exited] [Thread 0x7ffff6ae7700 (LWP 31578) exited] hashed 1030 of 1030 pieces writing metainfo file... done [Inferior 1 (process 31572) exited normally]

[pobrn]

BTW, I use the default make and make install option, it's fine to create torrent.

That could mean there's a problem somewhere in the threading code. Please note, that the just running make won't configure threads or OpenSSL, so hashing will be considerably slower.

The output is as follows. [...]

Is this the output after you ran the commands in my previous comment?

[Suitear]

BTW, I use the default make and make install option, it's fine to create torrent.

That could mean there's a problem somewhere in the threading code. Please note, that the default make won't configure threads or OpenSSL, so hashing will be considerably slower.

The output is as follows. [...]

Is this the output after you ran the commands in my previous comment?

Yes, step by step according to your instruction.

It can show the hashing process.

[Suitear]

update:

sorry for yesterday's unawreness of the last command 'bt'

whey I finally type bt, then the output is as follows.

(gdb) bt 0 0x00007ffff7e85c54 in SHA1_Final () from /lib/x86_64-linux-gnu/libcrypto.so.1.1 1 0x00005555555578c4 in worker (data=0x7fffffffdfa0) at hash_pthreads.c:201 2 0x00007ffff7fa2fa3 in start_thread (arg=) at pthread_create.c:486 3 0x00007ffff7bea4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[pobrn]

Does the segmentation fault always happen or just with specific files? Could it be that the sizes of the files are changing while mktorrent is running?

[Touceire]

You have to explicitly enable the features in the Makefile when running make USE_PTHREADS=1 USE_OPENSSL=1 USE_LONG_OPTIONS=1 or else the resulting binary will segfault everytime.

[Suitear]

Thanks. My bad. Now it seems OK.

So please update the Wiki of mktorent, in order to remind us that we should manually edit the Makefile file in order to use the recommended option in the wiki.

make USE_PTHREADS=1 USE_OPENSSL=1 USE_LONG_OPTIONS=1

[pobrn]

@Touceire can you elaborate? I have compiled mktorrent multiple times with various options without modifying the Makefile and the resulting executable has never once had segmentation fault. Is there some way to trigger it or when does it happen? I can see one way, that is, when you don't run make clean before make ..., then the resulting executable could indeed be not functional.

[Touceire]

@pobrn make USE_PTHREADS=1 USE_OPENSSL=1 USE_LONG_OPTIONS=1 works when using mktorrent from the build directory

$ git clone https://github.com/pobrn/mktorrent
Cloning into 'mktorrent'...
remote: Enumerating objects: 565, done.
remote: Counting objects: 100% (37/37), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 565 (delta 14), reused 10 (delta 3), pack-reused 528
Receiving objects: 100% (565/565), 183.70 KiB | 3.75 MiB/s, done.
Resolving deltas: 100% (369/369), done.
$ cd mktorrent/
$ make USE_PTHREADS=1 USE_OPENSSL=1 USE_LONG_OPTIONS=1
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c ftw.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c init.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c hash_pthreads.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c output.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c main.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c msg.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c ll.c
$ ./mktorrent ../TEST
mktorrent 1.1 (c) 2007, 2009 Emil Renner Berthing

hashed 951 of 951 pieces.
writing metainfo file... done

but segfaults after installing.

$ make install
cc -O2 -Wall -Wextra -Wpedantic  -DVERSION="\"1.1\"" -c sha1.c
cc -O2 -Wall -Wextra -Wpedantic  -DVERSION="\"1.1\"" -c hash.c
cc -O2 -Wall -Wextra -Wpedantic ftw.o init.o sha1.o hash.o output.o main.o msg.o ll.o -o mktorrent
install -d /usr/local/bin
install -m755 mktorrent /usr/local/bin/mktorrent
$ mktorrent ../TEST
mktorrent 1.1 (c) 2007, 2009 Emil Renner Berthing

Segmentation fault

However this problem doesn't occur when building mktorrent using make and a modified Makefile.

$ git clone https://github.com/pobrn/mktorrent
Cloning into 'mktorrent'...
remote: Enumerating objects: 565, done.
remote: Counting objects: 100% (37/37), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 565 (delta 14), reused 10 (delta 3), pack-reused 528
Receiving objects: 100% (565/565), 183.70 KiB | 2.52 MiB/s, done.
Resolving deltas: 100% (369/369), done.
$ cd mktorrent/
$ sed -i 's/#USE/USE/' Makefile
$ make
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c ftw.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c init.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c hash_pthreads.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c output.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c main.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c msg.c
cc -O2 -Wall -Wextra -Wpedantic -DUSE_PTHREADS -DUSE_OPENSSL -DUSE_LONG_OPTIONS -DVERSION="\"1.1\"" -c ll.c
$ make install
install -d /usr/local/bin
install -m755 mktorrent /usr/local/bin/mktorrent
$ mktorrent ../TEST
mktorrent 1.1 (c) 2007, 2009 Emil Renner Berthing

hashed 951 of 951 pieces.
writing metainfo file... done

[pobrn]

Ahh, I see, that's what I thought, I believe if you run

make USE_PTHREADS=1 USE_OPENSSL=1 USE_LONG_OPTIONS=1 install

then the problem will disappear.

The build system is quite fragile, it will be in the future.

[FranciscoPombal]

Better build system is ready but pending merge: https://github.com/pobrn/mktorrent/pull/50