It is saying that there is a header that exists in your forward reads which does not have a corresponding read in the paired (reverse) file. Make sure that each read in the R1*.fastq file has its paired read in the R2*.fastq file. Most likely the program doesn't have good enough error handling to deal with that, and so when it tries to make a contig from the forward and reverse for that header, it attempts to read from memory which has not been allocated (because there wasn't a matching R2 read, so space wasn't allocated for it)- hence the seg fault, Have you tried just running the remove.seqs command like it suggests?

Also yes trim.seqs (or some form of quality filtering) should be a normal part of your "pipeline". Sequence quality degrades at the ends of Illumina reads, due to read clusters on the flowcell becoming asynchronous (e.g. some fragments are 1 or more bases off, so there is conflicting fluorescence), meaning that the "confidence" in base calls is lower.. So usually we apply some quality threshold and trim all bases at the end of the read which don't meet that threshold (as determined by the Q score line for each read in the fastq).

cheers tyler..will try out your suggestions and see how it works out. 

Alternatively you could just clean and order your fastq files for any errors. Run a basic no-frills run of Trimmomatic. It will order pairs and remove any sequences that don't have a pair in the other file.