An other patch for command sig
by Olivier Daudel
Hi Dave,
I think we have an other small problem with sig :
crash> sig
PID: 14836 TASK: f7d89020 CPU: 1 COMMAND: "crash"
SIGPENDING: no
SIGNAL: 0000000000000000
BLOCKED: 0000000000000000
SIGNAL_STRUCT: c1e7ae00 COUNT: 1
SIG SIGACTION HANDLER MASK FLAGS [1] f5129804 817af58
0000000000000001 10000000 (SA_RESTART)
[...]
[63] f5129cdc SIG_DFL 0000000000000000 0 SIGQUEUE: (empty)
The last slot should be 64 ?
The patch is supposed to fix this problem.
I also indtroduce RT signals. I know this is trivial because the names
are SIGRTMIN+x (or SIGRTMAX-x). The motivation is the command sig -s.
By the way, there is a decision to enforce : do we leave the (null) to
remember that signals 32 and 33 don't exist (if i am correct) or do we
discard them ?
crash> sig -s ffffffffffffffff
SIGHUP SIGINT SIGQUIT SIGILL SIGTRAP SIGABRT SIGBUS SIGFPE SIGKILL SIGUSR1
SIGSEGV SIGUSR2 SIGPIPE SIGALRM SIGTERM SIGSTKFLT SIGCHLD SIGCONT SIGSTOP
SIGTSTP SIGTTIN SIGTTOU SIGURG SIGXCPU SIGXFSZ SIGVTALRM SIGPROF
SIGWINCH SIGIO
SIGPWR SIGSYS (null) (null) SIGRTMIN SIGRTMIN+1 SIGRTMIN+2 SIGRTMIN+3
SIGRTMIN+4
SIGRTMIN+5 SIGRTMIN+6 SIGRTMIN+7 SIGRTMIN+8 SIGRTMIN+9 SIGRTMIN+10 SIGRTMIN+11
SIGRTMIN+12 SIGRTMIN+13 SIGRTMIN+14 SIGRTMIN+15 SIGRTMAX-14 SIGRTMAX-13
SIGRTMAX-12 SIGRTMAX-11 SIGRTMAX-10 SIGRTMAX-9 SIGRTMAX-8 SIGRTMAX-7
SIGRTMAX-6
SIGRTMAX-5 SIGRTMAX-4 SIGRTMAX-3 SIGRTMAX-2 SIGRTMAX-1 SIGRTMAX
=================================================================
--- crash-4.0-3.2/task.c 2006-08-25 23:55:20.000000000 +0200
+++ crash-4.0-3.2-patch/task.c 2006-08-26 00:21:19.000000000 +0200
@@ -5522,7 +5522,6 @@
char *name;
char *altname;
} signame[_NSIG] = {
- /* 0 */ {NULL, NULL},
/* 1 */ {"SIGHUP", NULL},
/* 2 */ {"SIGINT", NULL},
/* 3 */ {"SIGQUIT", NULL},
@@ -5553,8 +5552,40 @@
/* 28 */ {"SIGWINCH", NULL},
/* 29 */ {"SIGIO", "SIGPOLL"},
/* 30 */ {"SIGPWR", NULL},
- /* 31 */ {"SIGSYS", NULL},
- {NULL, NULL}, /* Real time signals start here. */
+ /* 31 */ {"SIGSYS", "SIGUNUSED"},
+ /* 32 */ {NULL, NULL}, /* Real time signals start here. */
+ /* 33 */ {NULL, NULL},
+ /* 34 */ {"SIGRTMIN", NULL},
+ /* 35 */ {"SIGRTMIN+1", NULL},
+ /* 36 */ {"SIGRTMIN+2", NULL},
+ /* 37 */ {"SIGRTMIN+3", NULL},
+ /* 38 */ {"SIGRTMIN+4", NULL},
+ /* 39 */ {"SIGRTMIN+5", NULL},
+ /* 40 */ {"SIGRTMIN+6", NULL},
+ /* 41 */ {"SIGRTMIN+7", NULL},
+ /* 42 */ {"SIGRTMIN+8", NULL},
+ /* 43 */ {"SIGRTMIN+9", NULL},
+ /* 44 */ {"SIGRTMIN+10", NULL},
+ /* 45 */ {"SIGRTMIN+11", NULL},
+ /* 46 */ {"SIGRTMIN+12", NULL},
+ /* 47 */ {"SIGRTMIN+13", NULL},
+ /* 48 */ {"SIGRTMIN+14", NULL},
+ /* 49 */ {"SIGRTMIN+15", NULL},
+ /* 50 */ {"SIGRTMAX-14", NULL},
+ /* 51 */ {"SIGRTMAX-13", NULL},
+ /* 52 */ {"SIGRTMAX-12", NULL},
+ /* 53 */ {"SIGRTMAX-11", NULL},
+ /* 54 */ {"SIGRTMAX-10", NULL},
+ /* 55 */ {"SIGRTMAX-9", NULL},
+ /* 56 */ {"SIGRTMAX-8", NULL},
+ /* 57 */ {"SIGRTMAX-7", NULL},
+ /* 58 */ {"SIGRTMAX-6", NULL},
+ /* 59 */ {"SIGRTMAX-5", NULL},
+ /* 60 */ {"SIGRTMAX-4", NULL},
+ /* 61 */ {"SIGRTMAX-3", NULL},
+ /* 62 */ {"SIGRTMAX-2", NULL},
+ /* 63 */ {"SIGRTMAX-1", NULL},
+ /* 64 */ {"SIGRTMAX", NULL},
};
static void
@@ -5566,8 +5597,8 @@
if (!signame[i].name)
continue;
- fprintf(fp, "%s[%d] %s", i < 10 ? " " : "", -
i, signame[i].name);
+ fprintf(fp, "%s[%d] %s", i+1 < 10 ? " " : "", +
i+1, signame[i].name);
if (signame[i].altname)
fprintf(fp, "/%s", signame[i].altname);
fprintf(fp, "\n");
@@ -5591,12 +5622,12 @@
len = 0;
- for (i = c = 0; i < (_NSIG/2); i++) {
- mask = (ulong)(1) << i;
+ for (i = c = 0; i < (_NSIG); i++) {
+ mask = (ulonglong)(1) << i;
if ((sig = (sigset & mask))) {
- bit = ffs((int)sig);
+ /* bit = ffs((int)sig); */
sprintf(buf, "%s%s", c++ ? " " : "", -
signame[bit].name);
+ signame[i].name);
if ((len + strlen(buf)) > 80) {
shift_string_left(buf, 1);
fprintf(fp, "\n");
@@ -5827,19 +5858,19 @@
} else
use_sighand = FALSE;
- for (i = 1; i < _NSIG; i++) {
- fprintf(fp, "%s[%d] ", i < 10 ? " " : "", i);
+ for (i = 0; i < _NSIG; i++) {
+ fprintf(fp, "%s[%d] ", i+1 < 10 ? " " : "", i+1);
if (use_sighand) {
kaddr = sighand_struct +
OFFSET(sighand_struct_action) +
- ((i-1) * SIZE(k_sigaction));
+ ((i) * SIZE(k_sigaction));
uaddr = signal_buf + OFFSET(sighand_struct_action) +
- ((i-1) * SIZE(k_sigaction));
+ ((i) * SIZE(k_sigaction));
} else {
kaddr = signal_struct + OFFSET(signal_struct_action) +
- ((i-1) * SIZE(k_sigaction));
+ ((i) * SIZE(k_sigaction));
uaddr = signal_buf + OFFSET(signal_struct_action) +
- ((i-1) * SIZE(k_sigaction));
+ ((i) * SIZE(k_sigaction));
}
handler = ULONG(uaddr + OFFSET(sigaction_sa_handler));
----------------------------------------------------------------
Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
18 years, 2 months
Re: [Kgdb-bugreport] [RFC] [Crash-utility] Patch to use gdb's bt in crash - works great with kgdb!
by Vivek Goyal
On Thu, Aug 31, 2006 at 10:44:47AM +0530, Amit S. Kale wrote:
> On Thursday 31 August 2006 02:10, Vivek Goyal wrote:
> > On Wed, Aug 30, 2006 at 12:35:21PM -0700, Piet Delaney wrote:
> > > > Simple question -- and to be quite honest with you -- I don't
> > > > understand why you wouldn't want to simply use gdb alone
> > > > in this case?
> > >
> > > I don't see any reason for core file not to be read correctly by
> > > gdb. It's convenient to use gdb directly sometimes, for example
> > > while using the ddd GUI.
> >
> > You can run gdb to open core files as of today but the debugging
> > capability will be limited. For ex. kernel core headers have the info
> > of linearly mapped region only and they don't contain the virt address
> > info of non-linearly mapped regions. So one can not debug the non-linearly
> > mapped regions like modules.
>
> Adding this functionality should be easy. One only has to create crash file
> support for the osabi "Linux-kernel".
For module debugging, the analysis tool shall have to know some kernel
internals and traverse the page table. Gdb does not know about kernel
internals and we shall have to write page table walker etc.
Crash is already doing all this stuff. It also uses gdb as backend to
retrieve important debugging info etc. So why to duplicate the effort
and enable gdb to know about kernel internals and implement page
table walker etc. Anyway, a user space utility knowing about kernel
internals is bad because kernel changes so fast and keeping pace with
it becomes an maintenance nightmare.
On the side note, this year at OLS, maneesh conducted a BOF on sort of
creating a library in kernel like klibc which is maintained with kernel
and user space analysis tools can take advantage of that libarary and get
some reprieve in terms of maintenace overheads.
Thanks
Vivek
18 years, 3 months
How about an enumerated list of issues with the existing kgdb patches?
by Piet Delaney
On Wed, 2006-08-30 at 15:57 -0700, Andrew Morton wrote:
> On Wed, 30 Aug 2006 14:48:22 -0700
> Andrew Morton <akpm(a)osdl.org> wrote:
>
> > Plus: I'd want to see a maintainance person or team who
> > respond promptly to email and who remain reasonably engaged with what's
> > going on in the mainline kernel. Because if problems crop up (and they
> > will), I don't want to have to be the bunny who has to worry about them...
>
> umm, clarification needed here.
>
> No criticism of the present maintainers intended! Last time I grabbed the
> kgdb patches from sf.net they applied nicely, worked quite reliably (much
> better than the old ones I'd been trying to sustain) and had been
> tremendously cleaned up.
So why did you stop including them in the mm patch?
I recall your quality issue and Tom was all in favor
of resolving them. Was it too much work cleaning up the
patches to meet your needs that lead to the patch being
dropped from the mm series?
kgdb over ethernet is working great, and it looks like there
is plenty of support on the SF mailing list.
>
> But if we're to move this work from sf.net to kernel.org, the kgdb
> maintainers' workload, email load, turnaround time requirements,
> bug-difficulty and everything else will go up quite a lot, at least short-term.
> If they don't want to volunteer take that on (perfectly legit and sane) then
> things should stay as they are.
I've only read a positive point of view on resolving the issues on the
mailing list.
>
> (otoh, a merge would decrease their patch-maintenance load, and would
> increase the number of people who fix things for them, and might attract new
> maintainers).
I agree, it would likely attract many more maintainers and be easier
to maintain with git than patches.
>
> It's a big step.
How about a concrete list of patch quality issues that the group
can address to allow your weekly addition to the mm patch as a
set toward eventually integration.
Wouldn't getting kgdb back into the mm patch series be a reasonable
first step eventual maintenance in kernel.org? I hadn't even noticed
that it had been dropped until today's discussion in the crash mailing
list.
-piet
--
Piet Delaney
BlueLane Teck
W: (408) 200-5256; piet(a)bluelane.com
H: (408) 243-8872; piet(a)piet.net
18 years, 3 months
Re: [RFC] [Crash-utility] Patch to use gdb's bt in crash - works great with kgdb! - KGDB in Linus Kernel.
by Piet Delaney
On Wed, 2006-08-30 at 14:53 -0700, Randy.Dunlap wrote:
> On Wed, 30 Aug 2006 14:41:32 -0700 Piet Delaney wrote:
>
> > On Wed, 2006-08-30 at 16:40 -0400, Vivek Goyal wrote:
> > > On Wed, Aug 30, 2006 at 12:35:21PM -0700, Piet Delaney wrote:
> > > > >
> > > > > Simple question -- and to be quite honest with you -- I don't
> > > > > understand why you wouldn't want to simply use gdb alone
> > > > > in this case?
> > > >
> > > > I don't see any reason for core file not to be read correctly by
> > > > gdb. It's convenient to use gdb directly sometimes, for example
> > > > while using the ddd GUI.
> > > >
> > >
> > > You can run gdb to open core files as of today but the debugging
> > > capability will be limited. For ex. kernel core headers have the info
> > > of linearly mapped region only and they don't contain the virt address
> > > info of non-linearly mapped regions. So one can not debug the non-linearly
> > > mapped regions like modules.
> >
> > Amit's modified gdb might help for that problem. I haven't used
> > it but it allows gdb to load debug information about modules. You
> > can also use a script Amit wrote to explicitly load module info
> > into stock gdb; that also might work with kernel core files.
> >
> > >
> > > > kgdb isn't having any problems with kernel threads back traces.
> > > > The kernel objects are tweaked with dwarf code, but I see no
> > > > problem with using the same paradigm with crash. Works great.
> > > >
> > >
> > > Can you give some more details on what do you mean by kernel objects
> > > are tweaked with dwarf code.
> >
> > Attached is the cfi_annotations.patch patch from the kgdb-2.6.16 patch
> > which is part of the kgdb patch series. I believe George Anzinger used
> > a similar dwarf patch in the 2.6 mm series patches that Andrew provided.
> > I think Tom Rini wrote both of them.
>
> ENOPATCH
Opps.
-piet
>
> ---
> ~Randy
--
Piet Delaney
BlueLane Teck
W: (408) 200-5256; piet(a)bluelane.com
H: (408) 243-8872; piet(a)piet.net
18 years, 3 months
crash version 4.0-3.2 is available
by Dave Anderson
- Enabled CONFIG_SPARSEMEM support for ia64 kernels; tested on
RHEL5-alpha (2.6.17-1.2519.4.5.el5). Without this fix, crash
would fail during initialization with error message indicating:
"crash: CONFIG_SPARSEMEM kernels not supported for this architecture"
(anderson(a)redhat.com, dwilder(a)us.ibm.com)
- Moved read_in_kernel_config() to just after the internal gdb
module gets initialized. Without this fix, xen kernels built
with CONFIG_IKCONFIG would fail during initialization indicating:
"crash: gdb_interface: gdb not initialized?"
(anderson(a)redhat.com, moriwaka(a)valinux.co.jp)
- Implemented new s390/s390x command "s390dbf" command to print out
kernel traces from the s390 debug feature (s390dbf). The debug
feature is an s390 kernel trace API which uses wraparound buffers
to store trace records in memory. Many of the s390 device drivers
use this feature. There is some documentation of the s390dbf in
the kernel sources under /Documentation/s390/s390dbf.txt.
(holzheu(a)de.ibm.com)
- RHEL5-alpha kernel modules (only x86_64 confirmed) may possibly
fail to be loaded with the "mod" command due to dwarf2 errors
associated with the the split module.ko/module.ko.debug debuginfo
facility used by RHEL kernels. Bugzillas have been filed to
address those problems, but the crash utility's error-reporting
mechanism has beem modified to properly reflect that the internal
gdb module has failed to load the kernel module's debug data.
Without this fix, the "mod -[sS]" commands would silently return
without loading the module data because the "add-symbol-file"
operation inside the gdb module failed, did a longjmp(), and ended
up back at the crash prompt. That behaviour has been changed
to report the module name and the gdb error like so:
crash> mod -S
mod: /lib/modules/2.6.17-1.2564.1/kernel/drivers/scsi/scsi_mod.ko
gdb add-symbol-file command failed
crash>
Note that this problem occurs in all post-RHEL4 kernels, i.e.,
FC4, FC5, and now FC6 and RHEL5.
(anderson(a)redhat.com)
- Fix for runaway unkillable "repeat" command output that can happen
when scrolling is turned off and the command that was entered is
bogus. (anderson(a)redhat.com)
- Fix for "struct structure.member address" output when the member
is an array; additional members beyond the array contents would
get displayed. (anderson(a)redhat.com)
- Fix to internal gdb module to properly handle relocatable kernel
virtual addresses; this will be required for upcoming relocatable
RHEL5 kernels required for the kexec/kdump facility.
(anderson(a)redhat.com)
- Combined kernel_init(PRE_GDB) and kernel_init(POST_GDB) into a
single call to kernel_init() that is done after gdb is initialized;
verify_version() now called by kernel_init(). This is just a code
re-work, and does not change any functionality. (anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
18 years, 3 months
patch for command sig
by olivier.daudel＠u-paris10.fr
Hello Dave,
This is a very small patch for command sig.
I think it fixes the pointer problem.
--- crash-4.0-3.2/task.c 2006-08-23 17:09:48.000000000 +0200
+++ crash-4.0-3.2-patch/task.c 2006-08-25 00:03:48.000000000 +0200
@@ -5751,7 +5751,7 @@
int translate, sig, sigpending;
uint ti_flags;
ulonglong sigset, blocked, mask;
- ulong signal_struct, kaddr, handler, flags, sigqueue, next;
+ ulong signal_struct, kaddr, handler, flags, sigqueue, sigqueue_save, next;
ulong sighand_struct;
long size;
char *signal_buf, *uaddr;
@@ -5932,7 +5932,7 @@
mkstring(buf1, VADDR_PRLEN, CENTER|LJUST, "SIGINFO"));
else
fprintf(fp, "SIGQUEUE: (empty)\n");
-
+ sigqueue_save = sigqueue;
while (sigqueue) {
readmem(sigqueue, KVADDR, signal_buf,
SIZE_OPTION(signal_queue, sigqueue), @@ -5949,7 +5949,8 @@
sig = INT(signal_buf + OFFSET(sigqueue_info) +
OFFSET(siginfo_si_signo));
}
-
+ if (sigqueue_save == next)
+ break;
fprintf(fp, " %3d %lx\n",
sig, sigqueue +
OFFSET_OPTION(signal_queue_info, sigqueue_info));
----------------------------------------------------------------
Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
18 years, 3 months
SPARSEMEM, node_online_map, node_data etc...
by Dave Anderson
> But this kernel had two symbols(node_online_map, node_data).
> Can we get the node_mem_map of each node by using these symbols?
>
> Kernel gets the pglist_data of online nodes in next_online_pgdat() by
> the following method.
> 1. get the online NODE-IDs from "node_online_map".
> 2. get "node_data[NODE_ID]" as the pglist_data of online nodes.
>
> Thanks
> Ken'ichi Ohmichi
>
>
To avoid any duplication of efforts, I'm starting work on getting
the various "kmem" command options working again for RHEL5-alpha
x86_64 kernels, into which CONFIG_SPARSEMEM was recently introduced,
and CONFIG_NUMA is also configured. So that particular kernel uses
node_online_map and node_data. There are going to be some variances
among the different architectures in this area, but we have to start
somewhere. Expect fairly frequent version updates so that we can
all be on the same page...
Note that the first thing I ran into was a problem with the SPARSEMEM
support patch that I accepted into 4.0-2.22 -- which requires this fix:
--- memory.c 2006-08-22 14:27:51.000000000 -0400
+++ ../next/memory.c 2006-08-24 14:51:25.000000000 -0400
@@ -11374,13 +11374,16 @@ ulong
pfn_to_map(ulong pfn)
{
ulong section, page_offset;
+ ulong section_nr;
- section = pfn_to_section_nr(pfn);
+ section_nr = pfn_to_section_nr(pfn);
+ if (!(section = valid_section_nr(section_nr)))
+ return 0;
if (section_has_mem_map(section)) {
- page_offset = pfn - section_nr_to_pfn(section);
+ page_offset = pfn - section_nr_to_pfn(section_nr);
return (section_mem_map_addr(section) +
- (page_offset * PAGESIZE()));
+ (page_offset * SIZE(page)));
}
return 0;
This SPARSEMEM-only primitive could never have worked
since it was passing a section number into a function
expecting a section address (and even it did work, the
page address calculation was incorrect). So it always
returned 0, and therefore all of its consumers fail.
Dave
18 years, 3 months
As the kernel churns...
by Dave Anderson
...more crash utility bugs evolve.
I've renamed the "crash TODO list" link as the "crash TODO / BUG list"
on my people page, since just "TODO" is a bit optimistic.
New kmem command bugs have been added.
Dave
18 years, 3 months
per_cpu__xxxxx
by olivier.daudel＠u-paris10.fr
Hi Dave,
In reading your reply arroud per_cpu__xxxxx, i have understood my mistake.
For a new bee ... i think we could add someting like this in your help.
=====================================================
Spetial mention arround per_cpu__xxxx (with Intel only ?) in SMP context.
First step : you have to find __per_cpu_offset
crash> __per_cpu_offset
__per_cpu_offset = $1 =
{25182048, 25214816, 25247584, 25280352, 25313120, 25345888, 25378656,
25411424, 25444192, 25476960, 25509728, 25542496, 25575264, 25608032,
25640800, 25673568, 25706336, 25739104, 25771872, 25804640, 25837408,
25870176, 25902944, 25935712, 25968480, 26001248, 26034016, 26066784,
26099552, 26132320, 26165088, 26197856}
Second setp : use whatis, struct and sym with your per_cpu__xxxxx
crash> whatis per_cpu__irq_stat
irq_cpustat_t per_cpu__irq_stat;
crash> irq_cpustat_t -o
No struct type named irq_cpustat_t.
struct {
[0] unsigned int __softirq_pending;
[4] long unsigned int idle_timestamp;
[8] unsigned int __nmi_count;
[12] unsigned int apic_timer_irqs;
}
SIZE: 128
crash> sym per_cpu__irq_stat
c0407380 (D) per_cpu__irq_stat
Third step : use eval to determine the correct address
crash> eval c0407380 + 25214816
hexadecimal: c1c132e0
[...]
(one day, i shall try to do a small patch with options -h, -d, -o and
-2 (-b better, but already used) to select the proper choice when we
want to !!!)
Last step : you may now access to the per_cpu__xxxxx of second CPU
crash> rd -d c1c132e0 4
c1c132e0: 0 16918620 0 17218691
A nicer example, with a well defined structure :
crash> sym per_cpu__kstat
c0408be0 (D) per_cpu__kstat
crash> whatis per_cpu__kstat
struct kernel_stat per_cpu__kstat;
crash> eval c0408be0 + 25214816
hexadecimal: c1c14b40
[...]
crash> kernel_stat c1c14b40
struct kernel_stat {
cpustat = {
user = 535936,
nice = 3864001,
system = 33693,
softirq = 289,
irq = 526,
idle = 12992235,
iowait = 23818,
steal = 0
},
irqs = {8702265, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77403, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
4788, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
18433, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
}
----------------------------------------------------------------
Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
----- Fin du message transféré -----
----------------------------------------------------------------
Ce message a ete envoye par IMP, grace a l'Universite Paris 10 Nanterre
18 years, 3 months