View Issue Details

IDProjectCategoryView StatusLast Update
0003576GNUnetfile-sharing servicepublic2018-06-07 00:25
Reportercy1 Assigned ToChristian Grothoff  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSArchOS Version3.somethin
Product VersionGit master 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0003576: gnunet-publish can't publish a sub-directory named "gnunet"
DescriptionWhen publishing a directory using gnunet-publish if a sub-directory is named "gnunet" (and only "gnunet" seems to do this) then instead of the directory being added to the gnunetdirectory as "gnunet", if you're lucky it is added as NULL, and shows up as such when you try gnunet-directory on the resulting gnunetdirectory. using gnunet-download -R -o something.gnd produces a 'something' directory, but the subdirectory within it named "gnunet" is given the name of its CHK instead. Any other files in "something" will retain their names and save as something/whatever.txt or the like.

If you're unlucky, gnunet-publish just crashes unconditionally whenever it tries to publish a directory whose sub-directory is named "gnunet" and again, renaming that directory before publishing causes no problems or crashes.
Steps To Reproducesee attached shell script
Additional Information$ gdb --args gnunet -V something/

Preprocessing complete.

Program received signal SIGSEGV, Segmentation fault.
GNUNET_CONTAINER_meta_data_delete (md=0x0, type=EXTRACTOR_METATYPE_MIMETYPE, 
    data=0x0, data_size=0) at container_meta_data.c:401
401	  for (pos = md->items_head; NULL != pos; pos = pos->next)
(gdb) bt
#0  GNUNET_CONTAINER_meta_data_delete (md=0x0, 
    type=EXTRACTOR_METATYPE_MIMETYPE, data=0x0, data_size=0)
    at container_meta_data.c:401
#1  0x0000000000402cea in get_file_information (item=0x608320)
    at gnunet-publish.c:520
#2  0x0000000000402d6c in get_file_information (item=0x608320)
    at gnunet-publish.c:538
#3  0x0000000000402e99 in directory_trim_complete (
    directory_scan_result=0x608290) at gnunet-publish.c:566
#4  directory_scan_cb (cls=<optimized out>, filename=<optimized out>, 
    is_directory=<optimized out>, reason=<optimized out>)
    at gnunet-publish.c:664
#5  0x00007ffff736a6cb in run_ready (ws=<optimized out>, rs=<optimized out>)
    at scheduler.c:595
#6  GNUNET_SCHEDULER_run (task=0x3, task_cls=0x60a530) at scheduler.c:817
#7  0x00007ffff736560a in GNUNET_PROGRAM_run2 (argc=<optimized out>, 
    argv=0x605a90, binaryName=<optimized out>, binaryHelp=<optimized out>, 
    options=<optimized out>, task=<optimized out>, task_cls=0x0, 
    run_without_scheduler=0) at program.c:286
#8  0x00007ffff73658df in GNUNET_PROGRAM_run (argc=<optimized out>, 
    argv=<optimized out>, binaryName=<optimized out>, 
    binaryHelp=<optimized out>, options=<optimized out>, task=<optimized out>, 
    task_cls=0x0) at program.c:325
---Type <return> to continue, or q <return> to quit---
#9  0x0000000000401faf in main (argc=3, argv=0x605a90) at gnunet-publish.c:949
TagsNo tags attached.
Attached Files
gnunetfail.sh (592 bytes)

Activities

Christian Grothoff

2014-12-14 01:44

manager   ~0008678

I've tried but failed to reproduce the issue (I can publish, and download, using the provided shell script).

Nevertheless, looking at the crash, I can see why there might be an NPE, and I've fixed that in SVN 34549.

However, that doesn't explain the 'NULL' name you get for the 'gnunet/' directory.
Please let me know to what extend the attached patch helps. As I cannot reproduce the issue, more information would be helpful.

cy1

2014-12-14 04:29

reporter   ~0008679

I'll give it a shot sure.

cy1

2014-12-14 08:56

reporter   ~0008680

That fixed it, yeah.

cy1

2014-12-14 08:56

reporter   ~0008681

NPE fixed the problem

Christian Grothoff

2014-12-14 12:24

manager   ~0008682

That doesn't quite explain the behaviour you mentioned with the 'gnunet'-name specific stuff, or the name of the dir being 'NULL', or it being non-deterministic. As it was non-deterministic, maybe you can run it a few (100) times on your system to see if there is a 2nd issue? (and if so, re-open)? Thanks!

Issue History

Date Modified Username Field Change
2014-12-13 08:18 cy1 New Issue
2014-12-13 08:18 cy1 File Added: gnunetfail.sh
2014-12-14 01:40 Christian Grothoff Assigned To => Christian Grothoff
2014-12-14 01:40 Christian Grothoff Status new => assigned
2014-12-14 01:44 Christian Grothoff Note Added: 0008678
2014-12-14 01:44 Christian Grothoff Status assigned => new
2014-12-14 01:44 Christian Grothoff Status new => feedback
2014-12-14 04:29 cy1 Note Added: 0008679
2014-12-14 04:29 cy1 Status feedback => assigned
2014-12-14 08:56 cy1 Note Added: 0008680
2014-12-14 08:56 cy1 Note Added: 0008681
2014-12-14 08:56 cy1 Status assigned => resolved
2014-12-14 08:56 cy1 Resolution open => fixed
2014-12-14 12:24 Christian Grothoff Note Added: 0008682
2014-12-14 12:24 Christian Grothoff Fixed in Version => 0.11.0pre66
2014-12-14 12:24 Christian Grothoff Target Version => 0.11.0pre66
2018-06-07 00:25 Christian Grothoff Status resolved => closed