Question: How to download and use gcore extension to view user space stack? #1
Comments
|
You can download the latest gcore (crash-gcore-command-1.6.1.tar.gz) from: The latter has its instruction as well. If you have any questions, please let us know. |
|
Thanks a lot. It generates a partial core file. But it is not usable. GDB says : |
|
@d-hatayama san, this looks gcore side issue to me. (buffer overflow?) |
Me too.
Either is fine to me 😄 @Binary-Nerd , could you tell me the following things? which could be helpful to reproduce the issue.
|
|
@d-hatayama san, Please let me know if there is some test or anything i can do. |
Hmm, your original application. @Binary-Nerd The best is that you share the problematic vmcore. If I can look into the vmcore directly, I can figure out what is going on soon. Of course, I'd like you to avoid including important data in the vmcore to be shared. |
|
@d-hatayama san, |
|
I had not left any logs here, sorry. I tried to check whether the issue is reproducible on debian stretch with 4.9-rt kernel, but I didn't see the issue. I also looked into crash and crash gcore command from the viewpoint of basic memory management with malloc/free using valgrind and I didn't find anything that appears relevant to the issue. I think the issue is likely to depend on characteristics of your system and your application where the problematic kernel crash dump was collected; for example, multi thread program or (and) some kind of floating-point registers? Anyway, for additional information, could you provide a debug message during the execution of gcore command? You can enable debug message as follows: Also, I did valgrind support on crash during the investigation of this issue. If possible, could you try valgrind and provide me its result? To enable the feature, build crash command as: Then, run crash commnad using valgrind as: This feature is not released officially so you need to use the current master version. |
ah, I gave it my ack but it is still under review so you need to apply the patchset: |
|
@d-hatayama san The issue is still there on latest master. I ran crash with valgrind and following is the output: With |
|
Attaching gcore debug log file |
|
@d-hatayama san, |
|
@Binary-Nerd @k-hagio Sorry for the delayed response. I'm a little tied up now but I think I can look into the issue this weekend. |
|
@d-hatayama Thank you for looking into it. |
fill_files_note() creates NT_FILE note segment. There are two
A block in malloc() consists of header part and data part. The above Based on these information, there would be a buffer overrun at the The simplest workaround for @Binary-Nerd is to revert the commit that # git revert c52b6ed92937bec783174474dd069926fc4aedd4There is no problem without NT_FILES because gdb doesn't use NT_FILES I have no idea what the root cause is from the current There are two memmove() in fill_files_notes(). Could you check which 921static int
922fill_files_note(struct elf_note_info *info, struct task_context *tc,
923 struct memelfnote *memnote)
924{
...snip...
980 file_buf = fill_file_cache(vm_file);
981 dentry = ULONG(file_buf + OFFSET(file_f_dentry));
982 if (dentry) {
983 fill_dentry_cache(dentry);
984 if (VALID_MEMBER(file_f_vfsmnt)) {
985 vfsmnt = ULONG(file_buf + OFFSET(file_f_vfsmnt));
986 get_pathname(dentry, buf, BUFSIZE, 1, vfsmnt);
987 } else {
988 get_pathname(dentry, buf, BUFSIZE, 1, 0);
989 }
990 }
991
992 /* get_pathname() fills at the end, move name down */
993 n = strlen(buf)*sizeof(char) + 1;
994 remaining -= n;
995 memmove(name_curpos, buf, n);
996 progressf("FILE %s\n", name_curpos);
997 name_curpos += n;
998
999 *start_end_ofs++ = vm_start;
1000 *start_end_ofs++ = vm_end;
1001 *start_end_ofs++ = vm_pgoff;
1002 count++;
1003 }
1004
1005 /* Now we know exact count of files, can store it */
1006 data[0] = count;
1007 data[1] = size;
1008
1009 /*
1010 * Count usually is less than map_count,
1011 * we need to move filenames down.
1012 */
1013 n = map_count - count;
1014 if (n != 0) {
1015 unsigned shift_bytes = n * 3 * sizeof(data[0]);
1016 memmove(name_base - shift_bytes, name_base,
1017 name_curpos - name_base);
1018 name_curpos -= shift_bytes;
1019 }If in the first one, does strlen() in line 993 return a large value? |
I am looking for gcore extension to use it alongside crash so that i can generate the coredump of a process use gdb to analyse userside stack. If gcore has been replaced with a newer extension, please let me know.
The text was updated successfully, but these errors were encountered: