main.cc is attempting to parse cpu_gpu_mem_copy as kernel_launch

[FJShen]

accel-sim-framework/gpu-simulator/main.cc

Lines 82 to 100 in 17f819f

	unsigned i = 0;
	while (i < commandlist.size() || !kernels_info.empty()) {
	trace_kernel_info_t *kernel_info = NULL;
	if (commandlist[i].m_type == command_type::cpu_gpu_mem_copy) {
	size_t addre, Bcount;
	tracer.parse_memcpy_info(commandlist[i].command_string, addre, Bcount);
	std::cout << "launching memcpy command : " << commandlist[i].command_string << std::endl;
	m_gpgpu_sim->perf_memcpy_to_gpu(addre, Bcount);
	i++;
	continue;
	} else if (commandlist[i].m_type == command_type::kernel_launch) {
	// Read trace header info for window_size number of kernels
	while (kernels_info.size() < window_size && i < commandlist.size()) {
	kernel_trace_t* kernel_trace_info = tracer.parse_kernel_info(commandlist[i].command_string);
	kernel_info = create_kernel_info(kernel_trace_info, m_gpgpu_context, &tconfig, &tracer);
	kernels_info.push_back(kernel_info);
	std::cout << "Header info loaded for kernel command : " << commandlist[i].command_string << std::endl;
	i++;
	}

When concurrent kernel is enabled, this piece of implementation will attempt to parse as many lines in kernelslist.g as possible, assuming all of which are of command_type==kernel_launch. But when there are cpu_gpu_mem_copy commands after kernel_launch in kernelslist.g, this can cause the simulator to break at trace_parser.cc:282.
For example consider the kernelslist.g file of backprob-rodinia-2.0-ft:

MemcpyHtoD,0x00007fa371500000,16388
MemcpyHtoD,0x00007fa371504400,278596
kernel-1.traceg
MemcpyHtoD,0x00007fa37154c600,68
MemcpyHtoD,0x00007fa37154c800,278596
MemcpyHtoD,0x00007fa371504400,278596
kernel-2.traceg

The simulator will fail while parsing the 4th line.